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Elogios a Articulando Decisões de Design 


Articulando Decisões de Design é uma leitura obrigatória para qualquer 
pessoa envolvida com design, seja o design de produtos, de software ou de 
uma marca. E, quando digo envolvido, quero dizer ter qualquer tipo de 
participação. É um livro útil para engenheiros, gerentes de produto e 
executivos, tanto quanto o é para os designers. 

— Christian Manzella, diretor sênior e líder de UX na Samsung 


Articulando Decisões de Design, de Tom Greever, mudará o jeito que os 
designers falam de design. Adquira e leia este livro. 
— Tim O”Reilly, fundador e CEO da O"Reilly Media 


Tom fez um ótimo trabalho ao enfrentar um dos aspectos mais difíceis do 
design: falar com outras pessoas que não são designers e compartilhar o 
como e o porquê das decisões de design que você tomou. 


— Aaron Irizarry, líder de design de soluções de crédito da Capital One 
e autor de Discussing Design 


Enquanto a maioria dos livros sobre design menciona esses problemas de 
comunicação em uma caixa de texto secundária ou em uma nota de rodapé, 
Tom nos apresenta um livro inteiro de ferramentas testadas e comprovadas 
para transformar os designers em especialistas em comunicação. Fiel a seu 
título, é um livro fácil de ler e mais fácil ainda de recomendar. Estou 
empolgado com o fato de Tom nos ter dado essa joia de livro. 


— Richard Banfield, VP de transformação de design da 
InVision e autor de Design Leadership 


O livro de Tom é uma leitura essencial para designers que buscam ter 
controle sobre como o seu trabalho será consumido pelos stakeholders e 
clientes. Este livro é um guia de fácil leitura, que contém dicas práticas 
para articular decisões sobre produtos, com autenticidade, confiança e 
clareza. 

— Christy Ennis-Kloote, diretora de design da OpenDigital 


Articulando Decisões de Design descreve um modelo prático para você 
aprender a apresentar seu trabalho de design aos stakeholders e clientes da 
melhor maneira possível. Está repleto de exemplos e histórias reais que o 


tornam muito envolvente. 
— Cynthia Savard Saucier, diretora de UX da Shopify 


Ser capaz de “promover uma boa reunião” é um superpoder, 
particularmente para os designers, que, com muita frequência, partem do 
pressuposto de que o mais importante em uma reunião com os stakeholders 
é o trabalho de design que apresentarão. Com base em sua experiência, 
Tom mostra que o sucesso desse tipo de reunião, na verdade, depende mais 
de os stakeholders serem capazes de entender o que é mostrado a eles. Este 
livro oferece os modelos, os passos do planejamento, o vocabulário e (se 
você precisar) parágrafos prontos com expressões bem redigidas e 
habilmente escritas, que os designers precisam para começar a explicar de 
que modo o seu trabalho resolverá problemas reais, facilitará a vida dos 
usuários e por que ele merece o apoio da empresa. 


— Dan Klyn, arquiteto de informações e cofundador 
da The Understanding Group (TUG) 


Articulando Decisões de Design enfrenta o desafio de explicar as decisões 
de design de forma elegante, apresenta uma abordagem simples, 
permitindo que os designers (e as equipes!) consigam se alinhar com 
relação aos designs. Apenas criar o design não é suficiente, é preciso 
explicar o motivo por trás da decisão e enquadrá-lo no contexto do 
problema que ele pretende resolver. Todo designer e, a propósito, qualquer 
membro da equipe de produtos podem se beneficiar com este livro. 


— €C. Todd Lombardo, VP de produto da MachineMetrics 
e coautor de Design Sprint e 
de Product Roadmaps Relaunched 


Não importa se você é designer, desenvolvedor, gerente de produto, 
estrategista de conteúdo, arquiteto de informações, ou profissional de 
marketing ou de vendas, há uma boa chance de que você já tenha precisado 
apresentar suas ideias de design aos stakeholders em algum momento. É 
difícil. Todos terão uma opinião sobre o que você apresentar. E devem ter 
mesmo, pois o que você criar terá reflexos na marca e é um dos principais 
modos pelos quais os clientes ou consumidores irão interagir com a sua 
empresa. As pessoas com quem você trabalha se preocupam porque elas 
têm interesse no sucesso de seu design. Se quiser ser mais bem-sucedido 
para falar desse assunto, apresentá-lo e conseguir apoio, este livro é um 


ótimo ponto de partida. Tom Greever descreve táticas e soluções para 
enfrentar desafios organizacionais complicados, elas não só ajudarão você 
a fazer um trabalho melhor, mas também farão com que esse trabalho seja 
reconhecido no lugar em que você mais quer que o seja: no mercado. 


— Donna Lichaw, fundadora e CEO da SuperPowered 
e autora de The User”s Journey 
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[| Prefácio ] 


Em 2014 me pediram para submeter algumas ideias para palestras em uma 
conferência regional de UX nos Estados Unidos. Naquela época, eu 
trabalhava como consultor de design para algumas marcas muito famosas e 
estava ansioso para compartilhar parte do trabalho interessante que 
havíamos feito juntos. Submeti três resumos. Os dois primeiros eram sobre 
técnicas de design e abordagens que eu achava interessantes, isto é, 
métodos que havíamos usado em projetos para alcançar resultados eficazes 
no design. Eu estava empolgado com esses assuntos. O outro resumo era 
sobre como articular (explicar) decisões de design. Este me parecia trivial. 
Era, sem dúvida, importante, mas era algo que eu havia feito todos os dias 
em minha carreira. Eu sabia que outros designers também tinham de lidar 
com esse problema. É apenas parte do trabalho, certo? Parecia ser o assunto 
mais comum e tedioso possível, algo que eu fazia automaticamente, quase 
sem pensar. Naturalmente, foi esse que eles escolheram. 


Embora estivesse desapontado por não poder falar dos outros assuntos, me 
esforcei ao máximo na tentativa de reunir algumas ideias e princípios que 
pudessem ajudar os designers nessa área. Passei várias semanas pensando 
em como eu me comunico com as pessoas ao falar de design, quais os tipos 
de abordagens que adoto e como poderia ajudar outras pessoas a serem 
melhores, dando dicas práticas. Jamais pensei que essa palestra naquela 
conferência daria início a uma série de oportunidades que mudaram 
totalmente a minha carreira. 


Esse processo me permitiu ver como meu próprio trabalho estava repleto de 
exemplos em que uma boa comunicação havia resultado em um design 
melhor. Percebi que todos os meus designers favoritos eram pessoas que 
conseguiam explicar, de forma inteligente, por que faziam o que faziam. 
Percebi que muitos dos feedbacks que dou à minha própria equipe estão 
mais relacionados com o modo como o trabalho é apresentado do que com 
as habilidades para criá-lo. Desde então, ficou claro para mim que a 
maneira pela qual falamos de design com outras pessoas tem um impacto 
significativo no sucesso ao promover boas experiências. Essa é uma 


habilidade que muitos designers (até mesmo os designers mais experientes) 
não têm. O sucesso de nosso trabalho depende de nossa capacidade de obter 
o apoio de todos da equipe. Se não pudermos fazer isso, nossos designs 
jamais verão a luz do dia. 


Aprendendo a falar de design 


Minha jornada para trabalhar com UX começou na área de marketing. Fiz 
administração de empresas na graduação e, rapidamente, percebi a eficácia 
do design para dar vida aos produtos. Durante toda a época da faculdade, 
estudei design gráfico e web design por conta própria, fazendo projetos para 
pequenos negócios locais como freelancer a fim de me sustentar enquanto 
estudava. 


Sei que parece loucura, mas eu realmente gosto de entrevistas para 
emprego. Na faculdade, eu me candidatava praticamente para qualquer vaga 
e dizia sim para qualquer entrevista. Era uma oportunidade de baixo risco 
para praticar a maneira de falar sobre o meu trabalho. Eu adorava ver as 
pessoas olharem meu portfólio, comentarem sobre o que gostavam ou 
fazerem perguntas sobre por que eu havia feito o que fizera. Eu ficava 
empolgado ao explicar minhas decisões de design às outras pessoas naquela 
época, ainda fico hoje em dia. Adoro falar de design! 


Depois de ter me formado, passei por entrevistas para um cargo de gerente 
de criação de uma equipe de marketing interna com aproximadamente vinte 
pessoas. Minha última entrevista era com a vice-presidente de marketing. 
Ela fez perguntas sobre o meu portfólio, sobre o qual defendi meu ponto de 
vista facilmente. Fez perguntas sobre minhas experiências anteriores e 
passou os olhos pelo meu currículo, do qual eu, orgulhosamente, me 
gabava. Porém, ela foi direto ao ponto e me fez a pergunta mais memorável 
de minha carreira: “Suponha que eu tenha um novo projeto para você. Qual 
seria a primeira pergunta que você me faria sobre ele”. 


A resposta parecia ser fácil. Minha experiência era limitada, mas essa seria, 
talvez, a reunião mais comum para um designer: a reunião com um 
stakeholder. Sem hesitar, comecei com o que parecia ser uma abordagem 
testada e comprovada em todos os meus trabalhos anteriores: “Esse projeto 
é para um impresso ou para um site? Será colorido ou preto e branco? 


Usaremos fotografias de bancos de dados ou fotos originais? Quantas 
páginas terá o site ou o impresso? E, por fim, qual é o prazo?”. 


“Você está errado”, ela disse. “Nada disso realmente importa. O ponto mais 
importante sobre o qual você poderia me perguntar, isto é, a primeira 
pergunta que você sempre deve fazer é: “O que estamos tentando 
comunicar?"”. 


Fiquei atônito. Em silêncio. Eu sabia que ela tinha razão; além disso, ela 
havia exposto meu ego superficial de design de um modo que me fez sentir 
pequeno e totalmente perdido em relação a algo em que eu tinha muita 
confiança: a minha capacidade de falar sobre design. 


A boa notícia é que eu consegui aquele emprego e tive vários desde então, 
mas nunca mais me esqueci daquele erro. Eu não havia sido suficientemente 
astuto para reconhecer que minha stakeholder tinha uma agenda diferente 
da minha. Fracassei em entender quais eram suas necessidades ou em 
considerar suas preocupações. Para ela, era um projeto que dizia respeito à 
comunicação. Para mim, era somente uma questão de pixels. Naquele 
momento, percebi que minha capacidade de falar com outras pessoas sobre 
design era essencial. Eu devia levar em consideração as necessidades de 
meu público-alvo. Meus designs tinham de fazer algo para o cliente. Eles 
deviam resolver um problema. E, se não conseguisse explicar isso, eu 
estava destinado a cometer um erro novamente. Para que pudesse ter 
sucesso como designer, eu teria de descobrir como explicar aos meus 
clientes o que meus designs significavam. Teria de responder às suas 
perguntas de um modo que fizesse sentido para eles, e não para mim. Teria 
de explicar o raciocínio por trás de um design usando palavras que eles 
compreendessem, e esse design teria de atender às suas necessidades. 


Se eu pudesse fazer isso — pensei —, eu seria bem-sucedido. 


A UX ainda é jovem 


Muitas pessoas que trabalham atualmente com UX não se formaram em 
uma escola especializada na área nem tiveram aulas que ensinassem uma 
abordagem centrada no usuário. Nós migramos para a área de UX a partir 
de outras áreas da empresa: marketing, TI, design gráfico, pesquisa. Até 
mesmo pessoas especializadas em comportamento humano e psicólogos 


passaram a se mostrar relevantes na área de UX. 


Qualquer que tenha sido o seu caminho, muitos de nós que trabalhamos 
com UX temos histórias parecidas. A maioria de nós não começou com UX 
porque a área de UX ainda não existia. Desse modo, temos um mercado de 
design repleto de pessoas com experiências anteriores totalmente diferentes 
de seus cargos atuais. 


Além disso, em muitas empresas, o design sempre foi apenas um utilitário. 
Costumávamos contratar designers somente para que nossos produtos 
parecessem mais profissionais, para nos certificarmos de que a marca era 
consistente ou explicar uma ideia criativa. Hoje em dia, contratamos 
designers porque há problemas difíceis a serem resolvidos para que nossos 
produtos tenham sucesso no mercado. Um design ótimo é a norma 
esperada. Atualmente, os designers estão no centro do ciclo de 
desenvolvimento de produtos, de um modo que, no passado, era 
considerado desnecessário. Atualmente, os executivos também percebem a 
importância do design e querem ter influência no processo porque seus 
negócios estão em jogo. Nunca houve tantas pessoas na empresa a 
perceberem a importância do design para proporcionar uma ótima 
experiência aos usuários. 


O que acontece quando você toma um mercado cheio de pessoas criativas e 
inteligentes e as joga no meio de um ciclo de produto com problemas de 
usabilidade e objetivos de negócios a serem considerados? Bem, não é de se 
surpreender que haja um descompasso entre o que um stakeholder de 
negócios quer e o que um designer cria com tanto cuidado. E, então, os dois 
se encontram no meio, em uma reunião. 
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E nesse ponto que nos encontramos atualmente: em uma reunião com 
pessoas que não sabem como fazer o nosso trabalho, embora nos digam, 
consistentemente, como elas acham que deveríamos fazê-lo. É suficiente 
para deixar qualquer designer maluco. 


Este livro está na intersecção entre o mercado de design de UX e os 
negócios de produtos digitais, em que as expectativas anteriores de que o 
design é somente uma questão de ter figuras bonitas entram em conflito 
com ideias marcantes sobre como resolver problemas para os negócios. O 
crescimento e a maturidade do mercado de UX provocaram mudanças em 


nossas funções em vários aspectos, nenhuma tão significativa quanto a 
necessidade de dar explicações a outras pessoas que não compartilham de 
nossa experiência com design. 


Propósito deste livro 


O propósito deste livro é ajudar os designers a se comunicar melhor, a 
explicar, de forma inteligente, as suas decisões de design às pessoas que 
exerçam influência em seu projeto. A premissa básica do livro está centrada 
em uma reunião: uma reunião com clientes ou stakeholders na qual 
apresentamos nossas decisões de design e falamos sobre elas. Tudo foi 
escrito com essa reunião em mente: antes, durante e, até mesmo, depois 
dessa reunião. Tudo que descreveremos tem como foco essa reunião e foi 
escrito com o intuito de ajudar você a ser um profissional mais bem- 
sucedido para liderar, participar e obter apoio nessas situações. 


Algumas dessas reuniões envolverão muitas pessoas, mas a maioria 
envolverá poucas. Algumas poderão ocorrer em uma sala de reuniões, 
enquanto outras serão conversas improvisadas no corredor ou conversas 
online. Não fique obcecado com esses detalhes; em vez disso, mantenha o 
foco nos princípios gerais que podem ser aplicados em qualquer situação. O 
objetivo é se manter flexível e ser capaz de se adaptar rapidamente a 
diferentes situações. 


Descreverei, com detalhes, como anotar tudo por escrito, fazer perguntas, 
aprimorar suas habilidades como ouvinte ou fazer vários designs. Pode 
parecer que seriam necessárias semanas para se preparar para falar com 
alguém sobre o seu trabalho! Na verdade, porém, tudo acontece com muita 
rapidez. Às vezes, você terá bastante tempo para se preparar. Em outras 
ocasiões, será necessário dar uma resposta imediata e contar com seu 
discernimento para tomar decisões rapidamente. É por isso que desenvolver 
essas habilidades e transformá-las em hábito é tão importante. Você vai 
querer que articular (explicar) decisões de design seja algo que possa ser 
feito naturalmente, a ponto de você não precisar mais de um esforço 
consciente para aplicar todos os conselhos que estão neste livro. 


Permita-me ser bem claro: essa não é uma questão de uma mentalidade do 
tipo “nós versus eles”, que sugira que os designers estejam sempre certos e 


os stakeholders, por sua vez, sejam aqueles que tomam decisões ruins. 
Articular decisões de design diz respeito a criar um ambiente em que os 
stakeholders possam perceber claramente a expertise e ver o processo de 
raciocínio dos designers, de modo que queiram dar seu apoio. Trata-se de 
construir uma relação de confiança, demonstrar eficácia e fazer isso de uma 
forma agradável e convincente. 


Com efeito, um dos pressupostos assumidos neste livro é o de que o seu 
design é a opção correta. Devo supor que você fez suas pesquisas, tomou 
boas decisões, está resolvendo um problema para os negócios e o design 
que você propõe é a escolha certa. Se isso não for verdade, nenhum 
discurso que você possa fazer aos stakeholders fará qualquer diferença. 


Falar com as pessoas sobre design pode parecer uma aptidão básica, mas na 
verdade é uma tarefa muito difícil. Com base em minha experiência, posso 
dizer que os designers têm muita dificuldade para se comunicar de modo 
eficaz com as pessoas que não são designers. Assim, prossiga com a leitura 
e aprenda a se comunicar melhor com os stakeholders, mantenha sua 
sanidade e proporcione a melhor experiência possível aos usuários. 


Quem deve ler este livro 


Este livro foi escrito principalmente para designers que trabalham com 
stakeholders que não sejam designers: designers gráficos, web designers, 
designers de UX, de interação, de interface ou designers visuais. 


Designers 


Se você já passou pela experiência de ver um stakeholder insistir sobre uma 
mudança da qual você discordava, este livro foi escrito para você. Uma 
situação comum é os designers acharem que sua própria expertise e sua 
capacidade de julgamento são colocadas de lado por stakeholders que não 
conhecem muito de design. Este livro tem como propósito resolver esse 
problema e ajudar você a convencê-los de que suas decisões são as 
melhores opções. 


Designers experientes 


Talvez você considere que já trabalha há muito tempo nessa área e já tem as 


habilidades suficientes para articular as decisões de design. Isso pode ser 
verdade, mas com que frequência você aplica um esforço consciente, de 
forma bem planejada, para apresentar o seu trabalho? Além de confirmar o 
que você já sabe, apresentarei várias táticas de caráter prático para que você 
possa colocá-las facilmente em ação. 


Articular decisões de design não é algo que você possa aprender, se tornar 
especialista no assunto e nunca mais precisará aprimorar novamente. É uma 
tarefa que exige um esforço consciente constante, além de prática. Você 
pode até ser faixa preta, mas, sempre que entrar no ringue, poderá perder se 
não tiver se exercitado, ou não estiver pronto nem atento. 


Toda a equipe de produto 


Apesar de o livro ter sido escrito para designers, pelo fato de não ser uma 
obra de caráter técnico e lidar com vários problemas comuns, é possível 
relacioná-lo a vários outros cargos na empresa, e as pessoas que os ocupam 
poderão se beneficiar com as dicas e as boas práticas apresentadas. Já falei 
com vários pesquisadores, desenvolvedores, estrategistas de conteúdo e 
donos de produto (product owners) que se beneficiaram com os conceitos e 
as ideias contidos neste livro. 


Como este livro está organizado 


O Capítulo 1 começa mostrando como e por que a comunicação é uma parte 
essencial do processo de design nas empresas atuais. Nossos designs não 
falam por si mesmos; portanto, é preciso saber que uma comunicação clara 
é o componente que está faltando em vários processos de design. 


Os Capítulos de 2 a 10 estão organizados de forma linear e têm como ponto 
central a reunião com os stakeholders. Descreveremos o processo de como 
ocorrem a reunião e a apresentação do design. A cada passo, você verá uma 
linha do tempo (como a que apresentamos a seguir), a qual mostra em que 
ponto da reunião estamos. No caminho, discutiremos questões como: de 
que forma podemos entender os pontos de vista dos stakeholders, como ter 
empatia com eles e como fazer os preparativos necessários para a reunião 
com os stakeholders. Durante a reunião propriamente dita, veremos as 
habilidades implícitas e explícitas para ouvir, e aprenderemos a assumir a 


mentalidade correta antes de responder. Em seguida, proponho várias táticas 
e fórmulas simples que ajudarão você a obter apoio para os seus designs, 
dando a melhor resposta possível. Mesmo depois de concluída a reunião, 
será necessário fazer um acompanhamento e incluir ajustes em seu trabalho 
para garantir que a melhor experiência possível seja assegurada aos 
usuários. Do início ao fim, esses capítulos abordarão tudo que você precisa 
saber sobre a reunião com os stakeholders para falar sobre suas decisões de 
design. 
À reunião 


Fazer O 
Entender Ouvir Responder follow-up 


o——————)———————e os 


Como trabalhar com pessoas nem sempre é um processo linear exato, 
apresentarei algumas dicas e boas práticas que serão relevantes em vários 
outros aspectos de seu trabalho. Por exemplo, a abordagem de fazer boas 
anotações será discutida com detalhes, tanto no Capítulo 3 como no 
Capítulo 9, mas aplicá-la para documentar as decisões de design será 
relevante em todos os passos de seu processo de design. 


Por fim, encerro o livro com o Capítulo 11, “Como os executivos podem 
ajudar os designers”. Este capítulo foi escrito para os stakeholders que são 
executivos, mas não são designers, e tem como propósito servir de recurso 
para qualquer pessoa que esteja envolvida na tomada de decisões de design. 
Gerentes, executivos e líderes de negócios se beneficiarão ao aprender a 
trabalhar com os designers de modo mais eficaz. Incentivo os designers a 
compartilhar esse capítulo com os stakeholders executivos. 


Por que escrevi este livro 


Escrevi este livro porque gostaria de ajudar os designers e as empresas a 
promoverem boas experiências, já que há uma grande lacuna na 
comunicação entre os designers e os stakeholders. Para preencher essa 
lacuna, apresento conselhos reais e práticos que poderão ser prontamente 
aplicados em seu trabalho. Fiz isso, em parte, para documentar e dar clareza 
às minhas próprias ideias acerca de como o design é influenciado pela 
comunicação, mas também para ajudar a justificar as tarefas que executo no 
dia a dia. Este livro é a minha lista pessoal de verificação sobre como falar 


de design, e estou empolgado em compartilhá-la com você. Espero que seja 
uma ferramenta útil para você também. 


Conheci muitas pessoas ótimas por causa deste livro. Os relacionamentos, 
as conexões, as conversas, as dicas e os conselhos tiveram um valor 
inestimável. Foi uma experiência incrível e gostei muito de ser um 
facilitador nessa conversa sobre uma área importante de nosso mercado. 
Além disso, tive a oportunidade de viajar pelo mundo todo para dar 
palestras em conferências e trabalhar com equipes com as quais, do 
contrário, jamais teria o prazer de ter conhecido. Recebo mensagens de 
pessoas que me dizem que este livro mudou suas carreiras para melhor, ou 
que ele as ajudou a obter uma promoção. As pessoas compartilham histórias 
sobre como aplicaram uma tática e se ela funcionou ou não. Tive o prazer 
de liderar dezenas de equipes em workshops nos quais colocamos em 
prática, discutimos e aprimoramos essas habilidades pessoalmente. 


Gostaria muito de ouvir o que você tem a dizer também. Sinta-se à vontade 
para entrar em contato comigo, me seguir no Twitter, me adicionar no 
LinkedIn ou compartilhar uma história sobre como você lidou com esse 
problema. Acima de tudo, espero que o livro possa ajudar você também. 


Adicione-me no LinkedIn: https://www linkedin.com/in/tomgreever 


Siga-me no Twitter: Attps://twitter.com/tomgreever 


Siga-me no Instagram: Attps://www.instagram.com/tomgreever 


Você pode encontrar vários artigos, podcasts e vídeos sobre esse assunto em 
meu site: Attps://tomgreever.com 


Como entrar em contato conosco 


Envie seus comentários e suas dúvidas sobre este livro à editora escrevendo 
para: novatecOnovatec.com.br. 


Temos uma página web para este livro na qual incluímos erratas, exemplos 
e quaisquer outras informações adicionais. 


e Página da edição em português 
https://novatec.com .brilivros/articulando-decisoes-de-design 


* Página da edição original em inglês 


Para obter mais informações sobre os livros da Novatec, acesse nosso site: 


http://www novatec.com br 
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Ótimos designers se comunicam muito bem 


Você já teve de fazer mudanças em seu trabalho de design com as quais não 
concordava? Eu também! Não é fácil falar de design, particularmente com 
pessoas que não são designers. A capacidade de articular (explicar) decisões 
de design de modo eficaz é essencial para o sucesso de um projeto, pois, em 
geral, a pessoa mais articulada vencerá. Com efeito, eu diria que a diferença 
entre um bom e um ótimo designer está em sua capacidade não só de 
resolver problemas com o design, mas também de explicar, de forma 
articulada, como a sua solução os resolverá, de uma maneira que seja 
convincente, promova concordância e obtenha o apoio necessário para que 
o projeto prossiga. É disso que trata este livro: como obter apoio para as 
suas decisões de design. 


Há muitas pessoas envolvidas no processo de design. O que antes estava 
relegado a uma estética visual atualmente ocupa o centro da atenção de 
todos. As pessoas por toda a empresa percebem a importância de 
proporcionar uma ótima experiência aos usuários, e todos querem 
participar. Profissionais de marketing, executivos, desenvolvedores, 
gerentes de produto e até mesmo o pessoal da contabilidade vão querer 
dizer a você como eles acham que deve ser o design. As pessoas se sentem 
empolgadas com a UX (User Experience, ou Experiência de Usuário) 
porque reconhecem o efeito que ela tem sobre o produto, os negócios e o 
objetivo final da empresa no longo prazo. A boa notícia? Você é uma pessoa 
muito popular! 


A grande reunião 


Um certo domingo em janeiro, tive de pegar um voo tarde da noite para San 
Francisco para participar de uma reunião com um cliente na manhã 
seguinte. Mas essa não era uma reunião qualquer. Cerca de uma dúzia de 
pessoas de diferentes áreas da empresa estava apresentando seus designs 
para o CEO de um grande site de vendas a varejo. Vice-presidentes, 


diretores, donos de produto e designers de UX estavam todos envolvidos 
em organizar um evento de três horas que estabeleceria as bases dos 
projetos para toda uma temporada, desde que conseguissem o apoio desse 
único executivo. 


Depois de ter trabalhado com vários gerentes de produto e ter participado 
de várias reuniões, eu conhecia o trabalho que estava apresentando e 
comecei a preparar meus slides. Na sexta-feira anterior, eu havia 
participado de uma audioconferência de quatro horas, durante a qual todos 
da equipe colocaram em prática a sua apresentação para um VP, que deu 
feedback e fez sugestões sobre como apresentar as ideias para o CEO da 
melhor forma possível. 


Tudo estava centrado em torno de um único ponto: apresentar as ideias de 
design para um CEO com o intuito de obter seu apoio e conseguir sua 
adesão. Houve outras reuniões sobre a reunião, discussões sobre o que ele 
poderia dizer, trabalhos até tarde da noite para que tudo estivesse correto e 
reorganizações de agendas para fazer acontecer. Pessoalmente, eu passaria 
dezesseis horas viajando, duas noites em um hotel e um dia inteiro em uma 
sala de reuniões somente por causa dessa única reunião. Felizmente, correu 
tudo bem. O CEO foi muito simpático, ofereceu ótimos feedbacks e todos 
estavam prontos para implementar o trabalho para o qual haviam feito o 
design. 


Contudo, essa não é a parte importante dessa história. 


O que ficou para mim disso tudo foi o volume de esforços investido 
somente para explicar as ideias de design a uma única pessoa. O tempo que 
os outros designers haviam gastado para criar os mockups (protótipos) era 
trivial em comparação ao tempo e à energia gastos para encontrar a melhor 
forma de explicá-los. Falar sobre os designs era mais importante que os próprios 
designs. 


Talvez você não esteja em uma equipe grande como essa, ou não trabalhe 
para uma empresa grande na qual uma reunião com o CEO é um 
acontecimento relevante como esse; apesar disso, o princípio será o mesmo. 
O modo como falamos sobre o design para os nossos stakeholders é 
essencial para o sucesso de nossos projetos. 


O design é subjetivo... de certo modo 


Quando eu entrevisto designers para um cargo em minha equipe, sempre 
faço a seguinte pergunta a eles: “O que faz com que um design seja bom?”. 
O modo como as pessoas respondem a essa pergunta me diz muito sobre o 
que elas pensam sobre design e, em particular, sobre a UX. A maioria das 
respostas é previsível, mas, em geral, elas tendem a soar como: “um bom 
uso do espaço”, “simplicidade” ou, um dos meus favoritos, “quando não dá 
para remover mais nada”. Bem, não há nada de errado com essas respostas. 
Elas expressam o modo como muitas pessoas encaram o design, mas não 
são o que realmente faz um design ser bom aos olhos de um negócio. Não é 
a abordagem que eu desejo para os designers de minha equipe, pois essas 
ideias falam de subjetividade, de uma estética com a qual nem todos 
concordarão. 


Não tenho muita certeza de onde esses designers tiraram definições que 
soam mais como algo extraído diretamente das memórias de Jonathan Ive! 
Não acho que eles aprenderam isso na escola de artes. O que me preocupa é 
que eu acho que eles tomaram essas frases de efeito de um fenômeno de 
design de mídias sociais em que “UX” significa “algo que pareça tão 
interessante quanto um iPhone”. Eles as adotaram com base em uma 
mentalidade de competição por popularidade, na qual se acredita que beleza 
é o mesmo que usabilidade. É a mesma cultura que faz com que designers 
bem-intencionados criem um mockup (protótipo) para o “redesign” de 
qualquer site ou aplicação popular, sem ter qualquer pista sobre as 
necessidades daquele negócio. A solução diz mais respeito a curtidas do 
que à resolução de problemas. 


A verdade é que todo design é subjetivo. O que uma pessoa gosta, outra 
pessoa pode detestar. O que parece óbvio para mim pode não ser óbvio para 
você. O que funciona em um contexto poderia falhar lamentavelmente em 
outro. É por isso que o design é algo sobre o qual é tão difícil falar, 
particularmente com pessoas que não são designers. Há pouco 
entendimento comum sobre o que é, ou deveria ser, o design. 


Muitos caciques 


Seria fácil criar designs se não fosse o fato de que outras pessoas no projeto 


poderiam discordar de nossas decisões. Na verdade, elas vão! 


Há muitas pessoas que podem conhecer pouco, ou nada, de design, mas têm 
autoridade para supervisionar e determinar nossa prática de design. São 
investidas de interesse em participar da conversa, mas não são designers 
treinados nem têm o mesmo nível de conhecimento sobre design ou 
tecnologia que nós temos. 


Além disso, essas pessoas muitas vezes admitirão, com satisfação, que não 
são experts no assunto. Elas sabem que não sabem; apesar disso, continuam 
insistindo que suas ideias e opiniões estão corretas. Essa é uma das partes 
mais bizarras de nosso relacionamento com os stakeholders! As pessoas 
admitem prontamente que não são boas para fazer o nosso trabalho, mas 
insistem em fazer mudanças que acreditamos serem prejudiciais à 
experiência dos usuários. Elas dizem que confiam em nós como experts; 
apesar disso, com frequência, rejeitam nossas ideias. Essa situação pode ser 
extremamente humilhante e confusa, mas o problema talvez não seja 
exclusivamente deles. 


Esses stakeholders precisam fazer parte do nosso processo, mas nós 
resistimos em incluí-los de uma forma que possam contribuir, sem 
atrapalhar nossos objetivos. Precisamos descobrir como fazer isso. 


Todos são designers! 


Todos sabem o que é um bom design quando o veem, mesmo que não 
saibam como criá-lo. Parece frustrante (e até mesmo ridículo), mas é 
verdade. O mesmo pode ser dito no caso de outros tipos de arte, por 
exemplo, a música. Posso não saber como tocar um instrumento, mas posso 
decidir que tipo de música eu gosto (ou não gosto). Embora possa haver 
diferentes preferências, todos nós somos capazes de escolher o tipo de 
música que queremos ouvir, independentemente de saber reproduzir esses 
sons por conta própria. 
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Andy Zelman, Skeleton Claw Comics. (Usado com permissão: Attp://skeletonclaw.com) 


A interface é a sua interface 


Como o trabalho de design, com frequência, é muito visual, as pessoas se 
preocupam com a parte que veem, tocam ou com a qual interagem. Elas se 
preocupam com a interface. No entanto, quando seu trabalho é criar a 
interface de usuário, todos se preocuparão com tudo que você fizer! Todo o 
seu trabalho será exposto; portanto, naturalmente, atrairá mais opiniões e 


ideias em comparação com várias outras áreas da empresa. 


Nosso trabalho é essencial para o sucesso dos produtos de nossa empresa, 
portanto, devemos assumir a responsabilidade de mostrar às pessoas como e 
por que o nosso trabalho é tão importante. Essa parte não se dá 
automaticamente. Exige trabalho, exige prática, mas, acima de tudo... exige 
uma boa comunicação. 


Trabalho em equipe 


A colaboração parece ser a parte mais importante de um ótimo trabalho de 
design: diferentes opiniões reunidas para criar a melhor solução possível. É 
isso que todos realmente querem. A imagem que formamos é a de um grupo 
de intelectuais respeitáveis, debatendo as soluções corretas de forma 
apaixonada, resultando, em última análise, em uma discussão colaborativa e 
um design ideal que ninguém poderia ter imaginado sozinho. Um trabalho 
de equipe em sua melhor forma! Todos saem satisfeitos, realizados e são 
respeitados — prontos para o próximo desafio de design, certo? Achamos 
que queremos esse tipo de colaboração, mas a situação se torna muito mais 
complicada quando discordamos uns dos outros. Quando discordamos, 
tendemos a ficar na defensiva. Quando ficamos na defensiva, deixamos de 
manter o foco nos verdadeiros problemas. A reunião termina, não com 
colaboração, mas com um compromisso firmado por entre dentes e, muitas 
vezes, com uma experiência de usuário problemática. 


Em situações como essas, as reuniões podem facilmente se transformar em 
um design-por-comitê. Todos têm uma sugestão sobre como resolver um 
problema. Ouvimos diferentes opiniões de cada lado e somos incapazes de 
defender nossas próprias escolhas diante dessa enxurrada de feedbacks. 
Uma sugestão evolui para uma ideia sobre outra questão. Essa ideia faz 
surgir um pensamento sobre algo diferente. Se não houver um controle, a 
conversa poderá se perder em uma espiral descontrolada, transformando-se 
em uma confusão de ajustes bem-intencionados que, coletivamente, farão 
com que os objetivos gerais do projeto estejam condenados. Aquilo que 
pretendíamos fazer juntos foi turvado por um pensamento de grupo e por 
uma mentalidade de rebanho. Lembre-se de que trabalho em equipe sempre 
começa com trabalho. 


Botão do CEO 


Por causa desse problema, vemos situações como a do botão do CEO. 


O botão do CEO é uma requisição inusitada, ou ainda inesperada, de um executivo 
para que uma funcionalidade seja adicionada, a qual acabará totalmente com a 
estabilidade de um projeto e prejudicará o próprio propósito da existência de um 
designer. 
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É engraçado porque é verdade. Você poderia passar semanas ou meses 
desenvolvendo o melhor aplicativo possível. Sua equipe fez uso de todas as 
boas práticas existentes. Você fez testes de usabilidade para provar que a 
solução funciona. Apesar disso, um executivo pode chegar e acabar com 
tudo. Queremos evitar isso. 


Síndrome da página inicial 
Outro problema comum é a síndrome da página inicial. 


A síndrome da página inicial é uma condição na qual a tela inicial de uma 
aplicação ou de um site se torna um repositório para tudo, contendo uma infinidade 
de links, botões e banners de anúncios que arruinarão a trama da usabilidade, 
fazendo com que os designers chorem amargamente antes de dormir. 
Você sabe que, às vezes, não importa o quanto nos esforcemos, a página 
inicial simplesmente se transforma em uma confusão enorme. Todos 
querem que sua unidade de negócios esteja representada na página inicial. É 
como se algo não existisse se não estiver na página inicial. Aquela novidade 
que estamos lançando”? Coloque-a na página inicial. E aquele outro negócio 
que não está tendo um bom desempenho? Talvez, se o colocarmos na 
página inicial, vai melhorar. Parece familiar? Temos de aprender a lidar 
com esse fenômeno. 


A comunicação é o trabalho 


A boa notícia é que não precisa ser dessa forma. É possível evitar a 
desordem e o comprometimento tão frequentes no design organizacional 
por meio de uma melhor comunicação com os nossos stakeholders. Tenho 
constatado que a maior parte de problemas ou preocupações para os quais 
nosso stakeholders chamam a nossa atenção muitas vezes é apenas uma 
questão de mal-entendido ou falha na comunicação. O modo como falamos 
com eles sobre os nossos designs é essencial para garantir que sempre 


tenhamos a melhor experiência de usuário possível no final. 


Faz sentido quando pensamos no assunto. Todos os relacionamentos 
humanos, na verdade, nada mais são do que uma série de compreensões e 
incompreensões relacionadas. Nem sempre temos controle sobre como as 
outras pessoas nos entendem no início. Todos trazem suas experiências 
anteriores às conversas que temos no cotidiano. Entretanto, temos controle 
sobre como nos comunicamos com as pessoas de modo a influenciar esses 
futuros entendimentos. A forma como conversamos com as pessoas e aquilo 
que dissermos influenciarão suas respostas. 


Sei que disseram que seu trabalho era fazer o design dos produtos, mas, na verdade, a comunicação é 
o trabalho. 


Bons comunicadores vencem 


De modo geral, ser um melhor comunicador fará com que você tenha mais 
oportunidades. Fico impressionado com a quantidade de designers que se 


candidatam a um emprego, mas não têm as habilidades básicas de 
comunicação. As pessoas me enviam currículos sem explicações, se 
esquecem das entrevistas ou não seguem as instruções. No fim das contas, 
procuro somente candidatos que possam se comunicar bem; desse modo, os 
comunicadores ruins são rapidamente descartados. 


Ed 


E comum que meus líderes ou clientes afirmem que um dos motivos pelos 
quais me contrataram é porque é difícil encontrar pessoas que sejam 
confiáveis e possam se comunicar de modo eficaz. Já ouvi muitas histórias 
sobre ex-designers que simplesmente não eram bons em definir 
expectativas, seguir instruções ou articular (explicar) o seu trabalho de 
forma clara. A necessidade de trabalhar com outras pessoas no projeto, 
particularmente com desenvolvedores e gerentes, com frequência, é aquilo 
que diferencia os bons dos maus designers. Não é uma questão de ser capaz 
de criar o design mais inovador possível, mas de trabalhar com as pessoas 
de uma forma que elas tenham confiança em você e em sua expertise. 


Seu trabalho será mais fácil se você for um bom comunicador. Por mais que 
pareça estranho, talvez isso seja tudo que é necessário para diferenciar você 
dos outros designers — mesmo de designers que possam ser mais talentosos 
que você do ponto de vista artístico. É muito simples: bons comunicadores 
vencem. 


Ser articulado significa ter sucesso 


No entanto, a questão vai além de apenas usar palavras. Temos de 
transformar essas palavras em algo que provocará mudanças ou que levará 
as pessoas a apoiarem nossas decisões. Temos de explicar por que fizemos o 
que fizemos. Não se trata somente de usar palavras com frequência ou 
persistência; trata-se de usá-las de uma maneira que seja envolvente e 
convincente. Trata-se de ser articulado. 


O segredo para ser articulado é conhecer a mensagem que você quer 
comunicar, bem como a resposta que deseja receber. Se puder aprender a 
criar suas mensagens de modo que elas levem à resposta desejada, você 
perceberá que terá muito mais sucesso em conseguir aquilo que é 
importante para você. 


As melhores ideias (nem sempre) vencem 


Pode parecer que as melhores ideias sempre deveriam vencer, ou que um 
ótimo design deveria falar por si mesmo, mas não é assim que as situações 
se desenrolam na vida real. Acreditar que as melhores ideias são as que 
serão escolhidas é ser altruísta demais. Talvez elas devessem, mas trata-se 
do mundo real, e os seres humanos fazem parte da equação. As melhores 
ideias (infelizmente) se misturam em uma amálgama de reuniões nas quais 
outras necessidades competem por atenção. A pessoa que puder convencer 
a outra de que está certa é aquela que sairá vencedora. Seu design poderia 
ser revolucionário, mas é mais provável que uma pessoa que venda a ideia 
de modo agressivo e fale bem obtenha o apoio se puder convencer seu chefe 
de que ela está certa. 


Os designers que não têm habilidade para explicar por que fizeram o que 
fizeram acabam ficando do lado perdedor da discussão, forçados a fazer 
mudanças das quais discordam, simplesmente porque foram incapazes de 
rechaçá-las. Isso não quer dizer que o relacionamento com o stakeholder 
seja conflituoso. Não, essas discussões podem se assemelhar bastante com 
um bom e sólido trabalho em equipe. Porém, a incapacidade de se fazer 
ouvir e de articular o seu lado muitas vezes colocará você na posição de 
fazer mudanças que não proporcionarão os melhores resultados possíveis. 


Entretanto, ser articulado a respeito de nossos designs: 


Demonstra inteligência 


Você é inteligente, sabe do que está falando, tem expertise nessa área e as 
pessoas poderão confiar em você quanto à solução. 


Demonstra seu propósito 


Você pensou na solução, correu atrás dela e sua abordagem tem lógica. 
Essa não é apenas uma ideia aleatória, há propósito e foco. 


Expressa confiança 


Você sabe o que quer e como fazê-lo. Ter um argumento sólido mostra 
que você não está indeciso, mas está convencido do que diz. 


Mostra respeito 


Você dá importância suficiente às opiniões e ao tempo de todos, 
mostrando que está bem preparado. Você não desperdiça o tempo das 


outras pessoas nem as menospreza. 


Ser articulado quanto ao design é apresentar uma mensagem que explique 
por que fizemos o que fizemos para ajudar os stakeholders a entender o 
nosso raciocínio. Mais do que isso, podemos apresentar o nosso trabalho de 
modo que esteja de acordo com as necessidades e as expectativas deles 
também. Criamos laços de confiança com os stakeholders demonstrando 
nossa expertise por meio de lógica e raciocínio, dando explicações de um 
modo que faça sentido para eles. Desse modo, temos de ter domínio sobre o 
poder da comunicação, ser articulados e usar essas habilidades para ajudar 
as pessoas a verem que nossas decisões oferecem a melhor solução 
possível. Ser articulado nos ajudará a ter sucesso. 


Como ser um ótimo designer 


Para aprimorar as melhores práticas para articular as decisões de design, 
vamos analisar o que faz com que um design seja bem-sucedido, pois isso 
constituirá a base para que possamos falar dele. Vamos reduzir a UX à sua 
essência. Precisamos entender os fundamentos do que constitui uma ótima 
experiência para que possamos reproduzir essa forma de pensar e a 
abordagem. 


Três pontos essenciais 


Vamos voltar à pergunta: O que faz com que um bom design seja bom? 
Poderíamos debater a resposta, mas, quando se trata de criar a experiência 
do usuário, um design será realmente bom somente se ele resolver um 
problema. Na maioria das vezes, tentamos resolver problemas para os 
negócios; tentamos atingir algum objetivo que ajudará os negócios a 
crescer. Contudo, se colocarmos em prática uma abordagem de design 
centrada no usuário, devemos também fazer com que nossos designs sejam 
fáceis de usar para as pessoas que os utilizarão. 


Um aspecto de que muitas vezes nos esquecemos, porém, é que há outras 
pessoas envolvidas que exercem influência em nosso projeto. Apenas criar 


uma aplicação incrível não é suficiente; também precisamos do apoio de 
nossa equipe. Sem esse apoio, nosso projeto não poderá progredir. 


A diferença entre um bom e um ótimo designer está na capacidade não só 


de resolver o problema, mas também de explicar, de forma articulada, o 
modo como o design o resolve, de uma maneira convincente e que promova 
a concordância das pessoas. Se puder fazer isso, você será um ótimo 
designer. 


Portanto, eu diria que há três pontos em que todo design deve ser bem- 
sucedido: 


1. Deve resolver um problema. 
2. Deve ser fácil para os usuários. 
3. Deve obter o apoio de todos. 


Esses itens são a base para proporcionar uma ótima experiência aos 
usuários, a qual uma pessoa comum (por exemplo, seus stakeholders) possa 
entender. Projetos que fracassam, em geral, são insuficientes em uma dessas 
áreas. Se puder realizar os três itens, seu projeto será um sucesso. 


Vamos analisar cada um desses pontos com mais detalhes. 


Resolver um problema 


De tudo aquilo que estamos tentando fazer com o nosso trabalho, o 
principal é resolver problemas: objetivos de negócio, adesão, conversão, 
interação, feedback. Qualquer que seja o problema, nosso trabalho é 
encontrar uma solução e avaliar seu sucesso. Como saberemos se o nosso 
trabalho foi feito? Analisando os resultados antes e depois, monitorando 
alguma métrica específica e observando a sua melhoria. 


Espero que você e sua equipe já tenham essas metas, métricas ou KPIs (Key 
Performance Indicators, ou Indicadores Básicos de Desempenho) definidos 
para o seu projeto. Se não tiver, recomendo que você faça isso para que 
tenha uma referência a ser utilizada em todas as suas conversas. Projetos 
sem objetivos certamente fracassarão, pois não haverá nenhuma forma de 
convencer outras pessoas de que você está certo se não houver nada em 
relação ao qual seja possível avaliar o seu sucesso. Será somente uma 
questão de opiniões, e a subjetividade dificultará o progresso. Assim, se sua 
equipe não se preparou para definir esses itens no início, faça isso agora 
para preservar a sua própria sanidade. Descubra quais são os fatores mais 
importantes para seus stakeholders — impressões, conversão, cadastro de 
contas — e, em seguida, escolha um ou dois problemas mensuráveis que 


você gostaria de melhorar e anote-os. Defina-os como sua meta e use-os em 
seu favor quando conversar com outras pessoas. 


Embora, sem dúvida, sejamos adeptos de abordar esses problemas para 
encontrar soluções criativas, nem sempre estaremos em sintonia com o 
nosso próprio processo de raciocínio para ajudar outras pessoas a 
compreenderem o porquê de termos feito o que fizemos. É nesse cenário 
que a nossa intuição se torna muito importante, e é isso que nos torna bons 
designers: sabemos como resolver problemas com o design. Muitas vezes, 
para nós, é natural vermos uma solução sem pensar muito no assunto. Em 
outras ocasiões, poderíamos lutar para achar uma solução por meio de 
tentativa e erro. Qualquer que seja o caso, fazemos mudanças com o tempo, 
transformando nossas ideias em algo que agregará valor. A parte difícil, 
porém, é identificar o que está por trás dessa intuição. Do que é feito esse 
“parece certo”, de modo que possamos ajudar outras pessoas a verem do 
nosso ponto de vista? Como essa combinação de pequenas ações resulta na 
solução correta? A prática de resolver problemas com design também deve 
estar acompanhada de uma conscientização que nos ajudará a explicar 
nossas decisões às outras pessoas. 


Ao trabalhar com um design, você deverá ter muita consciência de cada 
decisão que tomar e do motivo por que a tomou. É preciso, o tempo todo, 
perguntar a si mesmo: “Qual é o problema que estou tentando resolver com isso?” 
No Capítulo 7, listarei alguns dos modos mais comuns com os quais 
descrevo minhas próprias soluções, mas, por enquanto, basta considerar que 
você precisa estar ciente de todas as mudanças que fizer, de todos os novos 
itens que acrescentar e de todas as reorganizações envolvidas para encontrar 
a interface correta. Essas escolhas inconscientes guardam o segredo para 
explicar seus designs às outras pessoas e garantir que sua perspectiva como 
um especialista no assunto permaneça no centro do processo final de 
decisão. 


A melhor forma é anotar tudo. Há algo no ato de passar seus pensamentos 
inconscientes para um formato mais tangível que permite que você se 
lembre de tudo que fez. Como há problemas mensuráveis que você está 
tentando resolver, anote o problema e, em seguida, liste suas soluções ao 
lado dele. Faça o que for necessário para documentar seu próprio processo 
de raciocínio. 


Gosto de fazer listas, então adoro digitar listas e deixá-las sincronizadas em 
todos os meus dispositivos. Algumas pessoas preferem usar papel e caneta, 
permitindo que sua mão execute os movimentos físicos necessários para 
conectar seus pensamentos ao mundo real. Você pode fazer isso com 
anotações simples ou com esboços mais complexos. Faça uma lista de suas 
soluções no papel, ou até mesmo desenhe um storyboard que mostre os 
efeitos antes e depois de seus designs. O método que você usar para anotar 
suas respostas não importa. A questão é fazer com que você pense em suas 
decisões de formas concretas. 


Eis alguns exemplos extraídos de meu próprio trabalho: 


Os usuários não percebem que os * Mova o contador de itens da lista para mais perto dos 
controles de filtro atualizaram a lista de | filtros para que o usuário possa ver o número mudar. 
resultados porque é uma operação 


. X * Mostre rapidamente um spinner de carregamento em 
Instantânea. 


cada caixa de seleção à medida que o usuário a 
selecionar. 


* Acrescente um botão Done (Pronto) para fechar o 
painel, de modo que o usuário saiba que a tarefa foi 
concluída. 


* Mova o título e a hero image? para a esquerda a fim de 


criar espaço para a CTA (Call to Action) à direita. 


Os usuários não avançam para os 
próximos passos a partir da página de 
entrada de marketing. 


* Mude a cor da CTA para vermelho; atualize a cópia. 


* Remova a imagem em segundo plano: ela desvia a 
atenção. 


* Posicione a lista “Next steps” (Próximos passos) de 
modo que, em geral, ela se sobreponha ao fold, fazendo 
com que o usuário queira fazer uma rolagem para a 
segunda CTA. 


Os usuários não estão adicionando Reduza o número de ações necessárias para adicionar um 

itens no carrinho de compras a partir da | item no carrinho de compras a partir da pesquisa. Adição 

view da lista de “resultados de com um único toque: 

pesquisa”. * Tocar em “Add to cart” (Adicionar ao carrinho) 
adicionará automaticamente o item no carrinho de 
compras, sem exigir uma quantidade ou outras 
informações. 


* No toque, o botão mudará para uma quantidade cujo 
valor inicial é 1. O usuário poderá incrementar a 
quantidade conforme achar necessário. 


* Remova o botão secundário “Add to cart” (Adicionar ao 
carrinho) para confirmação. 


* Nova mensagem com animação para informar que o 
item foi adicionado. 


* À chamada para ação “Ready to Checkout?” (Pronto 
para checkout?) é apresentada abaixo da mensagem. 


* Itens com opções, por exemplo, cor ou tamanho, terão 
um valor padrão automaticamente selecionado, mas 
haverá uma opção para que o usuário o modifique na 
view. 


Também pode ser conveniente descrever seus designs usando somente 
palavras. Boa parte de nosso trabalho é puramente visual, a ponto de ser 
difícil entender como “seria isso” em um mundo sem figuras. Como nosso 
objetivo final é explicá-lo a outras pessoas, por que não tentar descrever 
todos os detalhes na forma de sentenças, supondo que o leitor não seja 
capaz de vê-los? Como você descreveria seus designs a alguém por 
telefone? Ou por email? Descrever por escrito como você vê o seu trabalho 
revelará muitas de suas motivações, algumas das quais você nem terá 
percebido que existiam. O propósito desse exercício é ajudar você a revelar 
seu processo de raciocínio e descrever suas decisões de forma articulada, 
inicialmente para si mesmo. O objetivo não é fazer disso um substituto para 
demonstrar seus designs visualmente. 


Eis um exemplo extraído de um de meus projetos: 


A view de lista é exibida em ordem alfabética, por país, como padrão. O menu de 
ordenação padrão está disponível na parte superior à direita. Criei cada item da 
lista exatamente na altura apropriada para um dispositivo móvel que funcione por 
toque. Na extremidade esquerda de cada item, está a bandeira de cada país. 
Achamos que isso facilitaria a identificação para as pessoas. Ao lado da bandeira 


está o nome do país em negrito e, em seguida, uma breve descrição do projeto logo 
abaixo, em uma fonte menor em cinza. Uma referência rápida ao título do 
relatório. Na extremidade direita desses controles, há dois itens: (1) um resumo 
dos dados para o tipo de relatório selecionado pelos usuários. Por exemplo, a 
porcentagem, como 34% para a taxa de infecção, ou o total em um formato 
conciso, como 1,5 m, será exibido. (2) Uma seta informativa para sinalizar que há 
mais conteúdo “à direita” se o usuário tocar nesse item. A bandeira permitirá que o 
usuário encontre o país correto com mais rapidez, enquanto o pequeno trecho com 
dados o ajudará a saber se ele deve dar um toque para obter um relatório mais 
detalhado. Com esse design, os usuários poderão navegar rapidamente pela lista a 
fim de encontrar o relatório correto. 
A descrição não precisa ser longa nem deve consumir muito tempo. Não é 
um trabalho pesado. Faça o que for necessário para ajudar você a dar 
clareza ao seu raciocínio. Por exemplo, se você se vir comparando seus 
designs com outra plataforma conhecida, será um bom sinal se sua decisão 
tiver se baseado na resolução de um problema que a outra plataforma já 
pode ter solucionado. “Ao tocar o botão, o próximo conjunto de resultados 
será carregado do mesmo modo que faz o SocialApp.” Não há problemas 
em tomar decisões com base em outro aplicativo, mas nem sempre essa será 
a melhor solução. Contudo, isso permite que você se veja diante de uma 
série de novas perguntas a fim de explorar melhor o seu raciocínio: Por que 
o SocialAÃpp realiza essa tarefa dessa forma? Nosso contexto é 
suficientemente parecido? O SocialApp tem algum dado? Eles escolheram 
essa opção de forma deliberada? Sempre que você for capaz de descrever 
seus designs, uma parte de seu processo de raciocínio se revelará e isso 
pode ajudar você a encontrar as melhores maneiras de falar sobre ele. 


Não é preciso compartilhar essas anotações com o seu cliente ou o 
stakeholder. Talvez eles jamais as vejam, e isso não será um problema. Por 
enquanto, trata-se mais de exercitar o fato de haver um propósito do que de 
se comunicar com outras pessoas. A lição a ser aprendida nesse caso é que 
o processo de escrever sobre o que você criar ajudará seu cérebro a conectar 
os pontos entre o problema no qual você está trabalhando e o modo como 
seus designs os resolverão. Quanto melhor você for em fazer essas 
conexões, mais bem preparado você estará para falar delas com outras 
pessoas. Não importa o que funcione para você, o objetivo, nesse caso, é 
encontrar uma forma de transformar o seu processo de raciocínio em algo 


real, compartilhável e visível, além de identificar as palavras que ajudarão 
você a se explicar para outras pessoas de um modo que faça sentido. 


Ser fácil para os usuários 


Obviamente, se estamos adotando uma abordagem de design centrada no 
usuário, temos de criar algo que seja fácil para os usuários. Apesar de saber 
que a usabilidade é o desafio principal no design, pode ser difícil explicar 
isso para outras pessoas. Partirei do pressuposto de que você já sabe algo a 
respeito da usabilidade. O propósito não é dizer como fazer com que suas 
interfaces sejam fáceis de usar, mas ajudar a pensar em sua abordagem 
quanto à usabilidade, de modo que você possa falar dela com outras 
pessoas. 


Do mesmo modo que você estava resolvendo problemas e tomando 
consciência de suas decisões, o mesmo deve ser feito neste caso. A cada 
passo do processo, a cada decisão que tomar, pergunte a si mesmo: “Como 
isso afetará o usuário?” O problema para responder a essa pergunta é que, 
com frequência, simplesmente não sabemos como nossas decisões afetarão 
nossos usuários. Só poderemos dar nossos melhores palpites, testar e, então, 
tirar conclusões a partir do que observarmos. Assim como na seção anterior, 
faça anotações. Você deve ser capaz de responder a essa pergunta primeiro a 
si mesmo, a fim de que esteja preparado para dar essa resposta aos 
stakeholders. 


Uma forma de registrar como meus designs afetam os usuários é escrever 
uma história que seja baseada em uma sessão de usuário que eu tenha 
observado ou que seja, de modo geral, baseada em um caso de uso 
genérico. Eis alguns exemplos: 


Mudanças no design Como o usuário será afetado 


Mudanças no design Como o usuário será afetado 


Ter dois botões parecidos para Login e Sign Up (Cadastrar) um ao 
lado do outro é confuso para alguns usuários. Observamos usuários 

hesitarem para decidir qual botão deveriam escolher porque os 

botões são muito parecidos. Como Sign Up é o caso mais comum 
nesse contexto, fiz com que esse botão ocupasse a largura toda do 
contêiner e troquei o botão de Login por um link textual. Isso deve 
facilitar o cadastro de novos usuários, ao mesmo tempo que é fácil 
para os usuários existentes fazerem login. A maioria dos usuários 
existentes acessará diretamente a página de sua conta por meio de 
um login automático. Isso deve reduzir a confusão e aumentar a 
conversão. 


Already a member? Login here 


Quando estão em campo, os pesquisadores precisam de um acesso 
rápido aos seus dados, sem que precisem navegar pelo aplicativo. 
poco Nun PRETA Assim, em vez de manter a hero image na parte superior da tela de 
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entrada, estamos movendo-a para baixo, em favor de uma lista de 
“Recent Projects” (Projetos recentes) na parte superior. Os usuários 
57% “”º | ainda poderão ver essas informações importantes, mas seus 
a relatórios estarão mais facilmente disponíveis porque esse é o 

pi old principal uso que fazem do aplicativo, depois que já tiverem 


acessado os projetos. 


Falando de forma simplificada, a usabilidade diz respeito a duas questões: 
bom senso e pesquisa. No início de um projeto, talvez você não tenha muito 
com que trabalhar no que concerne aos dados ou observações de usuários. 
Você não terá muita escolha além de dar seu melhor palpite sobre o que 
funcionará para o usuário. Como especialista em usabilidade, você tem 
experiência no design de interfaces; portanto, será capaz de fazer 
suposições bem fundamentadas com base no que você acredita que 
proporcionará a experiência mais simples possível. É nessa hora que o bom 
senso entra em cena. De fato, não há motivos para raciocínios exagerados. 
Crie a solução mais simples que puder imaginar. Crie uma solução que faça 
sentido e siga em frente. 


É claro que o que você acha que faz sentido e o que um usuário faz, com 
muita frequência, são duas coisas diferentes. É por isso que fazemos 
pesquisas. Depois de termos apresentado alguns palpites bem 
fundamentados, precisamos testar nossas ideias usando pessoas reais. Uma 
pesquisa pode assumir várias formas, mas as ferramentas mais comuns são 
a análise de dados ou um estudo de usabilidade. Falaremos mais sobre esse 


assunto no Capítulo 6, mas permita-me dizer agora que o desafio com a 
análise de dados é que ela pode nos dizer somente o que os usuários fizeram. 
Ela não nos diz por que eles fizeram. A única forma de realmente saber 
como suas decisões afetarão os usuários é observá-los. Portanto, dê seu 
melhor palpite com os dados que você tiver, mas teste seus designs com 
pessoas reais e tome notas. Você poderá se surpreender com os resultados e 
estará em uma posição muito melhor para defender suas decisões. 


Obter apoio 


Não basta resolver problemas e criar um aplicativo fácil de usar; se um 
stakeholder não nos der seu apoio, não chegaremos a lugar nenhum. Você 
poderia ter o design mais inovador do mundo, mas, se ninguém de sua 
equipe entender o que você está tentando fazer, você não terá sucesso para 
implementá-lo. 


O que acontecerá se você não tiver apoio? Você terá sempre as mesmas 
conversas, repetidamente. Quando as pessoas não se lembram dos motivos 
pelos quais você fez o que fez (porque sua explicação não foi convincente 
nem memorável), elas voltarão ao assunto novamente na próxima reunião. 
“Por que é mesmo que concordamos em fazer isso?” Se as pessoas não 
estiverem convencidas de que você está certo, elas continuarão pensando 
em alternativas para sugerir. O escopo do projeto aumentará com o tempo, 
com as pessoas propondo o acréscimo de mais itens: um controle simples, 
mais um botão, um novo menu. Como resultado, você não conseguirá ser 
tão rápido quanto necessário porque estará atolado administrando 
solicitações. No fim, talvez você tenha de lançar um produto com uma 
experiência de usuário comprometida, tudo porque não foi capaz de 
conquistar a adesão dos stakeholders para a sua solução. 


Ter o apoio de todos de sua equipe é o foco principal deste livro. Não 
conseguiremos chegar a lugar algum, a menos que sejamos capazes de fazer 
com que todos estejam em sincronia e concordem em avançar na direção 
correta. É disso que trata a obtenção de apoio: convencer as pessoas a 
confiar em nós para a solução. Você deve criar um ambiente no qual todos 
saibam o que você está fazendo, confiem em sua expertise e apoiem suas 
escolhas para que você possa avançar para a próxima tarefa. 


Uso a palavra apoio deliberadamente, em vez de usar, por exemplo, 


aprovação ou concordância. Não conseguiremos fazer com que todos 
concordem com uma solução específica. A aprovação também não é a 
questão, pois ela implica certo nível de consenso. Isso não é um problema 
porque não é o que estamos buscando. Estamos buscando obter o apoio das 
pessoas — para nós, nossa expertise, nossa solução ou nosso plano para 
seguir em frente. É possível ter o apoio dos stakeholders, mesmo que eles 
discordem de nossa solução. Nesse aspecto, o que estamos buscando é uma 
concordância para seguir em frente, e não uma concordância quanto à solução. 
Nosso objetivo não é um consenso, mas ter impulso para seguir em frente. 
Simplesmente precisamos do apoio deles. 


Para obter o apoio necessário, temos de conhecer nossos designs fazendo a 
seguinte pergunta a nós mesmos: “Por que essa solução é melhor que a 
alternativa?” Implícito nesta pergunta está o fato de que sabemos quais são 
as alternativas e as consideramos ou até mesmo as testamos, e estamos 


preparados para explicar por que a nossa solução é melhor. 


Para tudo que estiver em nosso design, há outra maneira de fazer o mesmo. 
Para cada design que criarmos, há uma forma alternativa, em geral, oposta, 
de resolver o mesmo problema. É por esse motivo que há divergências 
quanto às soluções, para começo de conversa, e esse é um problema 
essencial na articulação das decisões de design. Os designers podem ser 
muito competentes para criar uma solução para o problema, mas somos 
menos adeptos de entender todas as soluções para o problema. Nós nos 
tornamos muito míopes quando achamos que encontramos a solução. 


Eureca! Nossa solução parece tão óbvia que há pouca necessidade de perder 
tempo considerando qualquer outra abordagem. (Afinal de contas, temos 
um sprint apertado e precisamos entregar algo para o cliente no fim do dia.) 
Apesar disso, esse tipo de pensamento quase sempre dá margem a uma 
conversa para a qual não estamos preparados: quando o cliente sugere uma 
ideia alternativa que não havíamos considerado. 


Ironicamente, em geral, temos consciência de algumas das demais 
alternativas. Nós, provavelmente, as testamos, movemos itens de um lugar 
para outro e, em algum momento, chegamos à solução que acreditamos ser 
a melhor. Contudo, não tomamos consciência de todos esses pequenos 
movimentos e, desse modo, estamos menos preparados para ajudar outras 
pessoas a entenderem o nosso processo de raciocínio. Do mesmo modo, 


muitas vezes sabemos o que nossos clientes irão sugerir. Se você já 
trabalhou antes com stakeholders, poderá ter uma boa noção de como eles 
reagirão (esse assunto será discutido com detalhes no Capítulo 3). Apesar 
disso, se você é capaz de adivinhar como eles reagirão, mas deixa de 
considerar essas alternativas e não sabe por que a sua solução é melhor, 
você terá dificuldades para convencê-los. 


A questão é esta: tenha consciência dos motivos pelos quais suas decisões 
de design são melhores que as alternativas. Assim como nos dois casos 
anteriores, anote suas respostas. Faça uma lista das outras maneiras pelas 
quais o problema em questão poderia ser resolvido. Crie uma série de 
designs alternativos, não os jogue fora, mas deixe-os disponíveis caso 
precise. Com essas alternativas, faça uma pequena lista das razões pelas 
quais você acha que elas não resolvem o problema tão bem quanto o design 
proposto por você. Pensar nessas outras opções de forma crítica ajudará 
você a se preparar para discutir suas decisões com outras pessoas. 


Às vezes, eu crio wireframes muito simples das alternativas, além de minha 
recomendação. Se o cliente começar a fazer perguntas sobre a solução 
proposta por mim, poderei rapidamente mostrá-los para demonstrar 
visualmente as diferenças. 


Categorias em Ferramentas 


Categorias em Ferramentas 


Mais vendidos em Ferramentas 


Categorias em Ferramentas Ver mais... Ver mais... 


Mais vendidos em Ferramentas 
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Mais vendidos em Ferramentas 


A. B. 


Faça acontecer 


Se vamos ser bem-sucedidos em falar de nossos designs com outras 
pessoas, devemos ser capazes de responder a estas três perguntas sobre o 
nosso trabalho: 


1. Qual é o problema que o nosso design resolve” 
2. Como o usuário será afetado”? 
3. Por que essa solução é melhor que a alternativa” 


O propósito de responder a essas perguntas é servir mais como um exercício 
para você compreender as suas decisões do que ser um método prescritivo 
para documentá-las. Não se preocupe demais com os detalhes sobre como 
você escreverá as respostas. Se puder responder a essas três perguntas, você 
estará no caminho certo para defender suas decisões junto às pessoas que 
exercem influência em seu projeto. Essas respostas estarão na base de sua 
resposta para quaisquer preocupações que um stakeholder tiver sobre seus 
designs. 


Sua capacidade de pensar em um problema e articular qualquer solução é 
mais importante do que sua capacidade de sempre fazer o design da solução 
perfeita. Quando outras pessoas perceberem que você pensou no assunto e 
há um propósito naquilo que você diz, elas estarão mais dispostas a confiar 
em você, mesmo que discordem. É assim que você se torna um ótimo 
designer: descrevendo e explicando seus designs a outras pessoas de uma 
forma que faça sentido para elas. 


Nesse aspecto, ser um ótimo designer diz respeito tanto às habilidades de 
comunicação quanto à aptidão em design. Você precisa entender suas 
decisões e, então, explicá-las de forma articulada a alguém que não saiba 
tanto de design quanto você. Usando essas perguntas como guia, você 
poderá encontrar melhores maneiras de explicar suas decisões de design, 
com o intuito de convencer as pessoas de que você está certo e garantir que 
os usuários tenham a melhor experiência possível. 


Embora seja fácil ver exatamente como ser mais articulado nos ajudará a ter 
sucesso, na prática, é muito mais difícil e complicado. Ser articulado é mais 
do que apenas saber dizer as coisas certas, pois nada do que dissermos terá 
qualquer efeito se não considerarmos primeiro o nosso público-alvo. 
Reconhecer a importância da comunicação no design faz com que seja 
natural dar o próximo passo em direção a ser um ótimo designer: começar a 
ver a situação do ponto de vista de nossos stakeholders. 


À reunião 
Fazer o 
Entender Ouvir Responder follow-up 


o—————)————————— OS 


1 N.T.: Jonathan Ive é um designer britânico que trabalhou na Apple como líder do 
departamento de design da empresa e foi responsável pela criação de vários produtos 
de sucesso da Apple. 


2 N.T.: Hero image é um conceito utilizado para destacar a imagem de um produto, 
com zoom adequado no produto e banners ao lado da imagem, realçando suas 
características principais. 


[2] 


Stakeholders também são pessoas 


À reunião 
Fazer o 


Entender Ouvir Responder follow-up 


———+»———+S——————s 


Antes de descrever os detalhes acerca de como ouvir e conversar com 
nossos stakeholders, gostaria de fazer uma pausa para analisar o 
relacionamento. A atitude mais importante que você pode tomar para 
melhorar a comunicação entre você e seus stakeholders é melhorar seus 
relacionamentos, conquistar sua confiança e estabelecer uma ligação que 
falará mais por você que as palavras que sairão de sua boca em uma 


reunião. 


Há muitos aspectos da vida e do trabalho que são construídos com base em 
relacionamentos. Não é apenas uma questão de quem você conhece, trata-se 
também da qualidade desses relacionamentos. Precisamos ver o mundo 
através dos olhos das pessoas que exercem influência em nosso projeto. 
Temos de entrar na mente delas, identificar o que as motiva e usar essas 
informações para nos ajudar a abordá-las de uma maneira que seja 
produtiva e valiosa para todos. 


O que é irônico para mim é que os designers de UX são muito competentes 
para colocar o usuário em primeiro lugar, ter empatia e tentar ver a interface 
da perspectiva dos usuários. Apesar disso, com frequência, fracassamos em 
fazer o mesmo com as pessoas que detêm a chave para o nosso sucesso. 
Vamos aplicar esses mesmos princípios às pessoas com quem trabalhamos 
para que possamos, juntos, criar um produto melhor. Precisamos ter tempo 
para entender nossos stakeholders. Mais que isso, precisamos nos envolver 
com eles em um nível pessoal e melhorar a qualidade de nossas interações. 


O propósito deste capítulo é dar um passo para trás no processo, antes de 
nos vermos atolados em um ciclo de reuniões. Começaremos com uma 
visão geral dos relacionamentos com nossos stakeholders para que 
possamos abordá-los do modo mais eficaz possível. 


Para isso, precisamos: 


Vê-los como seres humanos 


Todos estão envolvidos com outros acontecimentos que simplesmente não 
podemos prever. 


Criar experiências compartilhadas 


Encontrar um território comum é importante para conquistar a confiança 
dos stakeholders. 


Desenvolver empatia 


Conhecer profundamente o ponto de vista dos stakeholders, de modo que 
sejamos levados à ação. 


Fazer boas perguntas 


Entender como os interesses dos stakeholders, os quais vão além do 
trabalho, afetam seus pontos de vista. 


Além de passar a conhecer nossos stakeholders, é importante observar os 
indivíduos que fazem parte de nossa equipe e trabalhar para melhorar a 
qualidade de nossa comunicação com eles por meio das seguintes atitudes: 


Identificar quem exerce influência 
Com base no que já sabemos sobre as funções das pessoas na equipe, 
podemos compreender os valores que determinam suas reações ao nosso 
trabalho. 


Criar bons relacionamentos 


Atitudes simples podem fazer muito para estabelecer uma conexão: seja 
você mesmo, faça algo para as pessoas, dê algo a elas. A comunicação é 
mais fácil quando há bons relacionamentos. 


Conheça o ponto de vista deles 


Para abordar as pessoas e responder a elas, devemos conhecer primeiro o 
seu ponto de vista. Teremos a oportunidade de aprender a falar usando a 
linguagem delas, conhecê-las melhor e manter nosso projeto sob controle. 
Em última instância, nosso trabalho é aprender a fazer com que nossos 
stakeholders tenham sucesso, pois, se pudermos ajudá-los a ter sucesso, 
consequentemente, isso nos ajudará a sermos bem-sucedidos também. Não 


é fácil, mas podemos ter uma melhor noção de como são as pessoas quando 
nos lembramos de que elas são seres humanos, quando encontramos um 
território comum por meio de experiências compartilhadas, desenvolvemos 
empatia com o ponto de vista delas e fazemos perguntas que nos fornecem 
insights sobre o mundo em que elas vivem. 


Veja-os como seres humanos 


O problema com as pessoas é que somos todos muito imprevisíveis e, 
apesar disso, somos incrivelmente previsíveis ao mesmo tempo. Muitas 
vezes, as pessoas, em suas reuniões, estão lidando com situações, tanto em 
suas vidas pessoais como profissionais, que são mais importantes para elas 
do que o seu projeto atual de design. As pessoas são ocupadas (ou, pelo 
menos, elas acham que são). “Há muita coisa acontecendo no momento” ou 
“Tenho que participar de outra reunião”. Qualquer que seja o caso, muitas 
pessoas de cuja ajuda você precisa nem sempre estarão concentradas 
naquilo que você quer que elas se concentrem. Mais do que isso, as atitudes 
e as respostas dessas pessoas ao seu trabalho talvez tenham mais relação 
com algo que está acontecendo em uma esfera externa à conversa de vocês 
do que com aquilo que você está mostrando a elas. 


Antes de prosseguir, pare um instante e pense nas pessoas envolvidas em 
seu projeto. Traga à mente seus rostos, seus nomes e até mesmo seus cargos 
na empresa. Agora faça uma pausa e lembre-se disto: elas são seres 
humanos. Cada uma delas é um indivíduo único. Cada pessoa tem 
sentimentos, emoções e um passado que influencia seu presente todos os 
dias. Todas elas têm relacionamentos externos ao trabalho, que incluem 
amigos, esposos e esposas, pais e filhos. Quando saem de sua reunião, elas 
irão visitar suas mães no hospital. Uma delas terá de levar os filhos para um 
Jogo. E outra irá para casa para uma conversa difícil com a esposa. Apesar 
do fato de passarmos muito tempo juntos no trabalho, todos os 
relacionamentos mais importantes dessas pessoas encontram-se em outros 


lugares. 


Não podemos fingir que sabemos realmente o que acontece em suas mentes, 
mas podemos parar e perceber que o modo como elas respondem às nossas 
ideias e ao nosso trabalho talvez não tenha (ou provavelmente não tem) 
nada a ver conosco. Simplesmente há fatores, distrações e problemas de 


mais na vida de uma pessoa comum para que possamos supor que aquilo 
que queremos dela seja aquilo com o qual ela está preocupada. Em 
psicologia, o conceito de atribuição descreve como as pessoas veem umas 
às outras e, especificamente, como entendemos o comportamento de outras 
pessoas. O interessante é que a maioria das pessoas tende a ver o 
comportamento das outras como um reflexo dos traços particulares de suas 
personalidades, enquanto nós vemos o nosso próprio comportamento como, 
basicamente, circunstancial. Perceba que talvez tenhamos uma visão injusta 
das reações de nossos stakeholders. É natural que acreditemos que a 
personalidade dos stakeholders (“Eles não são designers”) é que faz com 
que eles discordem de nossas soluções, mas isso não é verdade. 


Sua colega foi meio rude com você no corredor sobre as novas interações 
que você criou”? Talvez ela esteja enfrentando alguns problemas em sua vida 
pessoal. Aquele rapaz em sua última reunião puxou seu tapete e acusou 
você de um problema pelo qual, na verdade, era ele o responsável? Talvez 
ele esteja sendo pressionado pelo chefe. Já aconteceu de um executivo 
comparecer na reunião e declarar que tudo teria de ser modificado? É 
possível que ele tenha acabado de sair de uma reunião e seu orçamento 
tenha sofrido cortes. As reações dos stakeholders ao nosso trabalho de 
design muitas vezes têm uma explicação que depende de uma circunstância 
da qual talvez jamais venhamos a saber. Sempre prefiro acreditar no melhor 
das pessoas a supor o pior acerca de suas intenções. 


Nunca me esqueço de uma ocasião em que um gerente veio até nossa 
equipe no fim do dia com uma solicitação de emergência. De repente, 
tínhamos de parar tudo que estávamos fazendo para que pudéssemos 
organizar alguns conceitos para uma ideia diferente e totalmente nova. A 
única explicação era que aquilo, repentinamente, havia se tornado uma 
tarefa de alta prioridade. Tentei entender a situação, mas simplesmente não 
fazia sentido e não condizia com o que havíamos combinado antes. Fizemos 
o melhor que podíamos para satisfazê-lo; contudo, alguns dias depois, ele 
desistiu do projeto e nos disse para retomar o nosso trabalho original. Mais 
tarde, descobri que ele havia perdido um de seus maiores contratos e estava 
na iminência de não cumprir suas metas financeiras, quando a época de 
distribuição de bônus estava se aproximando. Esse novo projeto era uma 
última tentativa para fazer algo acontecer, mas ele jamais nos teria dito isso. 


É claro que não foi apropriado que ele tratasse nossa equipe daquela 
maneira, mas não é essa a questão. A questão é que havia outros fatos 
acontecendo, sobre os quais não tínhamos conhecimento na época. E, na 
verdade, sempre haverá outros fatos acontecendo, sobre os quais jamais 
saberemos. Sempre há fatores que influenciam os comportamentos das 
pessoas, acerca dos quais não temos conhecimento. E sempre haverá 
ocorrências que simplesmente não poderemos prever. Sempre. Quanto 
maior a frequência com que você se lembrar disso, melhor será para você. 


Nosso trabalho como designers articulados é reconhecer o suficiente dessa 
realidade para que possamos conversar com as pessoas com quem 
trabalhamos, de forma a deixar de lado todas as distrações extras e chegar 
ao cerne do que precisamos saber para sermos bem-sucedidos. Precisamos 
reconhecer que o modo como as pessoas reagem ao nosso trabalho pode 
não ter nenhuma relação conosco ou com nossos designs. Assim, tão 
frequentemente quanto for necessário, pare, observe as pessoas ao seu redor 
e lembre-se disto: elas são seres humanos. 


Crie experiências compartilhadas 


Nossa incapacidade de ver através do ponto de vista de outra pessoa muitas 
vezes resulta de uma ausência de experiências compartilhadas. 
Simplesmente não temos o suficiente em comum com elas. Por que algumas 
pessoas parecem se relacionar melhor do que outras? Por que somos 
prontamente atraídos por algumas pessoas, mas não por outras? É porque 
temos algo em comum com elas. Quando temos experiências 
compartilhadas, temos algo sobre o que conversar. Quando não temos nada 
em comum com outra pessoa, é quase impossível conversar com elas. Tudo 
em que pensamos cai no vazio. No entanto, todos têm algo em comum com 
outras pessoas, é por isso que é muito fácil conversar sobre o clima. E, 
embora falar do clima seja uma experiência perfeitamente apropriada para 
compartilhar, se quisermos entender nossos stakeholders, temos de estar 
dispostos a ir além. 


Isso não quer dizer que precisamos bisbilhotar suas vidas pessoais. Na 
verdade, há várias maneiras de criar experiências compartilhadas com 
outras pessoas em um nível profissional. Pode ser algo tão simples quanto 
almoçar juntos ou tomar um drinque depois do trabalho. Não importa sobre 


o que você vai conversar: trabalho, a vida ou o programa a que você assistiu 
ontem à noite. A questão é que você afastará a si mesmo e o seu ego do 
trabalho e das pressões das exigências profissionais constantes. Você estará 
fora do escritório, fora de seu contexto usual, vivenciando algo com essa 
outra pessoa que, do contrário, não teria sido possível. 


Muitas empresas organizam eventos para fortalecimento de equipes e 
reuniões informais de funcionários exatamente por esse motivo. Contudo, 
se isso não faz parte de sua cultura, é possível fazer algo por conta própria. 
Outras maneiras de criar experiências compartilhadas incluem ir a uma 
conferência, trabalhar como voluntário no evento anual de caridade de sua 
empresa ou pedir um conselho à pessoa em questão: “Eu estava pensando 
em comprar um telescópio e fiquei sabendo que você se interessa por 
astronomia. O que você recomendaria?”. Encontrar formas de criar 
conexões com outras pessoas é um passo importante para compreendê-las. 


Uma viagem com Josh 


Nunca me esquecerei de quão drástico o meu relacionamento com um 
colega e a forma de encará-lo mudaram depois de ter vivenciado uma 
experiência com ele. Josh tinha um cargo semelhante ao meu, mas em um 
departamento diferente. Como consequência, usávamos muitos dos mesmos 
recursos compartilhados, e nossos caminhos se cruzavam ocasionalmente 
nos projetos. A impressão que eu tinha dele era de uma pessoa difícil de se 
relacionar: ele era desorganizado, insensível e eu não tinha respeito por ele. 
Era particularmente desafiador trabalhar em um projeto com ele porque eu 
sabia que ele teria muitas ideias diferentes e parecia que essas ideias sempre 
me davam mais trabalho. Contudo, por acaso, em certo ano, nós acabamos 
trabalhando na mesma conferência. Viajamos de carro juntos, em uma 
viagem de aproximadamente três horas. Ficamos no mesmo resort, que 
acabou se revelando um paraíso para relaxar. Passamos todos os dias fora 
de nosso contexto habitual organizando tudo, conversando com as pessoas e 
fazendo a maior parte das refeições juntos. Muito rapidamente, passei a 
conhecê-lo por meio de nossas experiências compartilhadas. 


Quase de imediato, minha opinião sobre Josh mudou. A partir de então, 
suas sugestões passaram a ser inovadoras! Ele não era mais insensível, mas 
somente um pouco ocupado demais e menos atento aos detalhes. Nada 


havia mudado, exceto o meu próprio ponto de vista sobre ele e o fato de 
termos experiências compartilhadas. Tornou-se muito mais fácil trabalhar 
com Josh e conseguir sua adesão nos projetos simplesmente porque tivemos 
essas experiências compartilhadas. Na verdade, ele passou a ser um de 
meus maiores aliados. 


Você não precisa fazer uma viagem de carro com os stakeholders para ter 
experiências compartilhadas. Encontrar esse território comum pode ser tão 
simples quanto trazer à tona um assunto interessante antes de a reunião 
começar. Você poderia comentar o fato de eles terem um dispositivo com a 
tecnologia mais recente, estarem vestindo uma roupa da marca que você 
aprecia ou falar sobre o souvenir de Paris que eles têm na mesa. Tudo que 
você puder fazer para encontrar um território comum entre vocês fará muito 
para lembrar a todos (inclusive a você mesmo) que vocês têm interesses 
comuns. Somos mais do que simples manipuladores de pixels. Somos 
pessoas. Muitas vezes, o único elemento que nos impede de desenvolver 
bons relacionamentos somos nós mesmos. 


Desenvolva empatia 


As pessoas na área de UX falam muito sobre desenvolver empatia com os 
usuários. Se pudermos ter verdadeira empatia com eles, criaremos 
aplicações melhores. Mas, e quanto aos nossos stakeholders? Precisamos ter 
empatia com eles também, se realmente quisermos a sua aprovação. 


Desenvolver empatia com nossos stakeholders significa tentar olhar para o 
nosso projeto através do ponto de vista deles, para que não fiquemos na 
defensiva nem sejamos superprotetores no que diz respeito às nossas 
próprias ideias. Perceberemos que suas reações e sugestões se baseiam em 
uma realidade que, para eles, é mais importante que a nossa. Se tiver 
empatia com os stakeholders, você não só entenderá o ponto de vista deles, 
como também será levado à ação; você vai querer fazer mudanças em seus 
designs porque percebe as dificuldades deles. 


É nesse ponto que o script vira a seu favor. Se tiver uma verdadeira empatia 
com seus stakeholders, você verá sua função como a de alguém que os 
ajudará a ter sucesso. Seu sucesso depende do sucesso deles. Você 
encontrará meios para resolver problemas para eles, seja se adequando ao 
ponto de vista deles em seu trabalho de design, ou simplesmente 


apresentando o trabalho de uma forma que seja condizente com as 
necessidades deles. Você perceberá a urgência de atender às necessidades 
dos stakeholders e vai querer fazer algo a respeito. 


Isso não quer dizer que você fará qualquer coisa, ou fará tudo que eles 
disserem. Significa somente que sua prioridade na comunicação com eles 
mudou, passando de uma posição defensiva para uma posição de 
solidariedade. Vocês ainda poderão discordar da solução, mas, ao menos, 
você estará mais bem preparado agora para conversar com eles sobre suas 
escolhas. Ter empatia com nossos stakeholders é importante para 
estabelecer uma mentalidade de base que nos permitirá dar a melhor 
resposta possível ao feedback que eles nos derem, conforme veremos no 
Capítulo 5 e nos capítulos posteriores. Não podemos esperar ouvi-los e 
responder aos seus feedbacks sem antes ter empatia com eles. 


expertise 


conhecimento ARE 
nos negócios 


do domínio 


O cérebro do stakeholder desmistificado! Nossos stakeholders têm um conhecimento valioso do 
domínio e informações sobre os negócios de que precisamos para sermos bem-sucedidos. 


Liderando com visão 


Certa vez, trabalhei com um executivo que era um pensador visionário, mas 
estávamos desenvolvendo um MVP (Minimum Viable Product, ou Produto 
Mínimo Viável) simples para a primeira versão. Nas duas primeiras 
reuniões, ele ficou desapontado com nossas funcionalidades básicas. Ele 
sabia das restrições do projeto, mas precisávamos de sua adesão para que 
tivéssemos o seu apoio. Ele estava sempre presente, mas não ficava muito 
empolgado. No processo de trabalhar com ele, tentei ver o nosso projeto de 
seu ponto de vista. Como executivo, ele sempre tinha uma visão geral de 


tudo que estava acontecendo, de uma altitude de 10 mil metros; apesar 
disso, estávamos mostrando a ele alguns detalhes que seriam apenas um 
pequeno pontinho no radar desse produto. Ele estava olhando para o fim do 
jogo, um lançamento ruidoso com fanfarras, mas nós estávamos 
concentrados nesse passo intermediário, o aqui e o agora. 


Assim, a partir daquele momento, decidi levar dois mockups (protótipos) 
diferentes em cada reunião. Um era esse MVP básico, modesto e simples. O 
outro era uma imagem inovadora, sem limites, de algo incrível, que jamais 
seríamos capazes de desenvolver, pelo menos no curto prazo. Porém, 
consegui prender sua atenção mantendo os dois conceitos diante dele. Fui 
capaz de conduzir nossas conversas com essa visão incrível de um futuro 
almejado, ao mesmo tempo, mostrando e conseguindo seu apoio para aquilo 
que nos permitiria dar um passo naquela direção. Ele podia ver para onde 
estávamos indo e, desse modo, estava mais disposto a dar seu apoio ao 
nosso MVP. 


Eu não poderia ter me preparado com essa abordagem se não tivesse sido 
capaz de ter empatia pela sua posição. Isso exigiu mais trabalho de minha 
parte, mas, no longo prazo, valeu a pena, pois fez com que nossos designs 
tivessem prosseguimento. Ele pôde confiar mais em nós porque conseguia 
perceber a visão. Na verdade, tenho notado que, muitas vezes, uma boa 
prática ao trabalhar com os executivos é mostrar tanto o que é possível fazer 
no curto prazo como o que poderá ser feito no futuro. Essa abordagem cria 
uma energia que mantém todos empolgados, aumentando as chances de os 
stakeholders apoiarem você. 


Faça boas perguntas 


Ver a partir do ponto de vista de nossos stakeholders exige muito trabalho e 
paciência. Não é algo que conseguimos fazer automaticamente, mas exige 
tempo e prática. Você deve aprender a ver as situações do ponto de vista de 
seus stakeholders, do mesmo modo que faria com os usuários de sua 
aplicação — fazendo perguntas. Se quisermos ver nossos stakeholders como 
seres humanos, criar experiências compartilhadas e desenvolver empatia 
pela situação deles, a melhor atitude que podemos tomar é simplesmente 
fazer perguntas. 


Meu cunhado Lars é uma das pessoas mais interessantes que conheço. A 


qualquer lugar que ele vá, as pessoas gostam de conversar com ele. O 
engraçado é que ele não parece ser uma pessoa muito extrovertida. Sua 
personalidade é um pouco reservada, ele é cuidadoso ao falar e nunca fala 
demais. Apesar disso, parece que as pessoas são atraídas por ele. Quando as 
pessoas o veem, elas param para conversar. Se o avistam do outro lado de 
uma sala, elas vão atrás dele. Por quê? É porque Lars é realmente bom em 
fazer perguntas. As pessoas adoram conversar com Lars porque ele é bom 
em fazê-las falar. Você sai de uma conversa com Lars com a sensação de 
que acabou de conhecer alguém que é realmente inteligente, interessante e 
extremamente interessado em sua vida. Ele é um ótimo parceiro de 
conversa, não porque é bom em falar, mas porque é bom em fazer 
perguntas. 


A habilidade de Lars em fazer as pessoas falarem mostra que precisamos 
ser melhores em fazer perguntas às pessoas sobre elas mesmas, de modo 
que elas se sintam valorizadas e fiquem à vontade para falar conosco. Essa 
abordagem para relacionamentos e conversas nos ajudará a criar uma 
reputação que faça com que as pessoas queiram conversar conosco e, como 
consequência, nos ouçam mais nas ocasiões que forem mais importantes. 


Seja pessoal 


As pessoas adoram falar de si mesmas. Mesmo as pessoas que são menos 
inclinadas a dar informações ainda gostam de conversar sobre temas que 
são importantes para elas. Portanto, reserve tempo para saber um pouco 
mais sobre cada pessoa para que você possa começar a ver que a vida delas 
não gira em torno do trabalho. Não faça perguntas do tipo sim/não e não 
faça perguntas pessoais demais a ponto de ir além do comportamento social 
costumeiro. Mantenha a leveza, mas deixe que as pessoas digam o que 
estão dispostas a dizer. Faça perguntas como: 


* O que você fez nesse fim de semana? 

* Como foi o seu feriado? 

e Você assistiu a algum bom filme recentemente” 
* Então, o que há de novo? 


Essas perguntas, ainda que sejam bem básicas, são importantes. São 
suficientemente genéricas a ponto de serem apropriadas para qualquer 


público-alvo e podem dar início a conversas que ajudarão você a ver as 
situações do ponto de vista delas. Elas abrirão um caminho que permite que 
você possa conhecer melhor as pessoas e, em algum momento, possa fazer 
perguntas mais específicas. 


Se você souber que as pessoas têm filhos, pergunte sobre eles. Todos falarão 
dos filhos para você, e é algo que muitas pessoas têm em comum. O mesmo 
vale para bichinhos de estimação, as pessoas adoram falar de seus bichinhos 
de estimação. Eu estava em uma reunião individual com uma stakeholder. 
Enquanto caminhávamos para a sala de reuniões, perguntei se ela tinha 
algum bichinho de estimação. Ela pegou o telefone para fazer login na 
câmera remota que ela havia instalado no cercado para gatos do lado de fora 
de sua casa. De forma conveniente, a conversa passou rapidamente para 
tecnologia e o aplicativo que controlava a sua câmera. Isso se converteu 
naturalmente em uma discussão sobre a UX. Fazer perguntas sobre 
bichinhos de estimação deu a ela um assunto sobre o qual ela gostava de 
falar e me deu uma oportunidade para demonstrar minha própria expertise 
no processo, conquistando a sua confiança e respeito para o projeto que 
estávamos prestes a discutir. Você não imagina como fazer boas perguntas 
poderá melhorar seus relacionamentos e ajudar você a conquistar a 
confiança necessária para falar de seus designs. 


Ofereça informações sobre si mesmo 


A estrada, porém, não é uma via de mão única. Você também deve oferecer 
algumas informações sobre si mesmo para fazer as pessoas falarem. 
Encontre um tema que seja de seu interesse e faça perguntas a respeito do 
assunto: 


* Fui acampar no último fim de semana. Você gosta de acampar? 
* Recebemos minha família para um jantar ontem à noite. Você gosta de 
cozinhar? 
e Assisti a esse filme ótimo ontem. Você já o viu? 
Fornecer às pessoas um vislumbre de sua própria vida é uma ótima maneira 
de passar a impressão de que elas são como você. Não importa como elas 


responderão a você na ocasião, talvez você descubra que têm muito em 
comum. Eu estava visitando um cliente em Nova York que se ofereceu para 


me levar para almoçar em seu carro. Era um carro pequeno, mas, por acaso, 
percebi que ele tinha um sistema de escapamento modificado. Fiz perguntas 
sobre o sistema porque estou restaurando, eu mesmo, um carro clássico, e 
estava curioso sobre o seu interesse sobre carros. Contei-lhe sobre o meu 
projeto e começamos a conversar sobre carros em geral. Essa conversa se 
transformou em uma história sobre como ele havia feito um empréstimo 
para comprar um avião quando tinha somente vinte e poucos anos. Ele 
ainda era o proprietário desse avião e adorava pilotar. Eu estava trabalhando 
com essa pessoa havia vários meses, mas não fazia ideia de que ele era um 
piloto! Com efeito, sempre que conversamos hoje em dia, ele fala das 
últimas novidades sobre pilotagem porque sabe que eu tenho interesse no 
assunto. Revelar alguns de meus próprios interesses possibilitou que 
estabelecêssemos um território comum. 


Seja profissional 


Ver as situações do ponto de vista de nosso stakeholder, porém, exige que 
saibamos como eles encaram seus trabalhos e o nosso projeto também. 


Portanto, é igualmente importante saber como as pessoas pensam no 
contexto de nosso trabalho. Faça perguntas como: 


* O que você achou da reunião da semana passada? 
* Como está o seu trabalho naquele outro projeto”? 
* Você está muito ocupado esta semana? 


Se você perceber que está entrando em conflito com as pessoas no 
comando, é comum que haja divergências entre os objetivos estabelecidos 
ou as prioridades do projeto e os objetivos e prioridades individuais. Nesse 
caso, sugiro que você seja o mais direto possível ao tentar descobrir os 
pontos de vista e as perspectivas das pessoas em situações nas quais isso 
possa ser difícil de ler. Por exemplo: 


* Qual é a sua opinião sobre esse projeto”? 
º Como esse projeto afeta o seu trabalho? 
* Qual é a sua prioridade nesse projeto? 


Permitir que as pessoas expressem suas próprias opiniões ou perspectivas 
pode fornecer insights que difiram dos objetivos da empresa ou do projeto. 


Eu estava tendo um pouco de dificuldade com um gerente que estava nos 
pressionando quanto a algumas prioridades, e suas sugestões pareciam estar 
em conflito com o nosso objetivo de melhorar a conversão. Perguntei a ele 
como o nosso projeto o afetaria, e ele disse que sua maior prioridade era 
migrar da antiga plataforma o mais rápido possível porque, durante a 
transição, ele estaria pagando pelo desenvolvimento de ambas. Enquanto as 
duas plataformas estivessem em seu orçamento, ele estaria sujeito a muita 
pressão. No entanto, ele jamais teria conseguido a aprovação para 
desenvolver a nova plataforma se o objetivo definido não fosse uma 
melhoria na conversão. Assim, embora nossa meta oficial fosse aumentar a 
conversão, sua agenda pessoal consistia em substituir a plataforma o mais 
rápido possível. Saber disso melhorou significativamente a nossa 
capacidade de nos comunicarmos sobre os designs e as prioridades pelo 
resto do projeto. 


Novamente, o ponto importante ao fazer perguntas é fazer com que a outra 
pessoa fale com você sobre o que é importante para ela. Você quer entender 
melhor o ponto de vista dela para que tenha uma ideia melhor de como lhe 
responder quando for necessário. É assim que passamos a ter conhecimento 
do ponto de vista de outra pessoa e nos preparamos para ter um melhor 
relacionamento, uma melhor comunicação e mais sucesso para proporcionar 
a melhor experiência possível aos usuários. 


Identificando as pessoas que exercem influência 


Agora que já consideramos as melhores maneiras de ver a situação pelo 
ponto de vista de nosso stakeholder, vamos analisar os tipos de pessoas que 
influenciam nossos projetos para que possamos personalizar essas 
abordagens com elas. 

Em qualquer projeto, há diversas pessoas que exercem influência em seu 
resultado. Para simplificar, vamos supor que haja somente três tipos 
principais de pessoas que você precisa compreender: 


Pessoas de sua equipe que exercem influência 
São as pessoas que estão em sua equipe direta. 


Executivos que exercem influência 


São as pessoas que supervisionam o seu projeto. 


Pessoas externas que exercem influência 
São as pessoas externas à sua equipe. 


Dependendo da posição dessas pessoas em relação a você, pode ser difícil 
conhecê-las bem, o suficiente para compreendê-las e entender seus pontos 
de vista. Nosso trabalho, porém, é identificar essas pessoas e procurar 
entendê-las da melhor forma possível. 


Pessoas de sua equipe que exercem influência 


As pessoas que estão sujeitas à sua influência direta são aquelas que você vê 
e com quem interage no cotidiano. Elas provavelmente incluem outros 
designers, desenvolvedores, gerentes de projeto ou donos de produto. 
Pesquisadores, estrategistas de conteúdo e nossos chefes imediatos também 
fazem parte desse grupo. Talvez seja mais difícil trabalhar com essas 
pessoas regularmente porque... bem, somente porque você tem que 
trabalhar com elas regularmente! No entanto, a vantagem é que você terá 
muitas oportunidades para conhecê-las, descobrir o que as motiva e 
personalizar a forma como você as aborda de uma maneira que seja 
condizente com as necessidades delas. 


Em geral, sua equipe é o melhor lugar para encontrar pessoas que possam 
ajudar você em seu projeto. Você terá oportunidades diárias para construir 
esses relacionamentos a fim de melhorar a experiência do usuário. Quanto 
mais tempo você puder passar com essas pessoas descrevendo soluções, 
falando da importância do projeto e determinando um vocabulário básico, 
melhor será para você no que se refere a criar uma cultura que siga a sua 
liderança no caso de decisões importantes. É um trabalho árduo porque 
você terá de mostrar sua determinação todos os dias e encontrar formas de 
liderar, mesmo que você não seja o líder. As pessoas de sua equipe que 
exercem influência são os seus aliados mais importantes. 


Executivos que exercem influência 


As pessoas que estão fora de sua influência imediata, mas têm interesse e 
exercem influência em seu projeto, são os executivos. O caso mais comum 
é de um executivo ou gerente que supervisiona sua equipe, talvez um ou 
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dois níveis acima dela. É o chefe: é a pessoa de cujo apoio você mais 
precisa. Em equipes pequenas e em startups, pode ser o CEO, com quem 
você também trabalha com muita proximidade. Em empresas de grande 
porte, é um diretor ou um VP, e talvez você não tenha um acesso regular a 
eles. Qualquer que seja o caso, essas pessoas são importantes para o sucesso 
de seu projeto. Sem o apoio delas, você não terá o que precisa para ter 
sucesso. Em vários aspectos, comunicar-se de forma eficaz com essas 
pessoas é o foco principal deste livro. 


Felizmente, não há mais do que um ou dois executivos principais que 
exerçam influência em seu projeto. A dificuldade está no fato de que, em 
geral, não nos encontramos com eles com muita frequência para realmente 
entender o seu ponto de vista. Eles estão sempre se alternando entre 
assuntos e projetos diferentes, e talvez não tenham muito tempo nem 
capacidade mental para se dedicarem à sua apresentação cuidadosamente 
preparada. Nesse caso, você terá de fazer uso de muita perspicácia em todas 
as reuniões, conhecer as pessoas que os conhecem (por exemplo, uma 
assistente administrativa ou alguém que responda diretamente a eles) e 
fazer o melhor que puder com as informações limitadas que tiver. Em suma, 
é preciso entendê-los e responder a eles de modo quase instantâneo. Com o 
tempo, você desenvolverá um ritmo que poderá melhorar a sua 
compreensão e ajudará você a se comunicar com eles. 


Pessoas externas que exercem influência 


O terceiro grupo de pessoas — que importam menos para suas tomadas de 
decisão no cotidiano, mas também podem ajudar em seu trabalho ou 
prejudicá-lo — são as pessoas externas que exercem influência. Esse grupo 
está em uma parte diferente da empresa e, provavelmente, não tem relação 
com o seu trabalho ou projeto; todavia, alguém dos outros dois grupos 
poderia dar ouvidos a essas pessoas, e elas poderão afetar o seu projeto 
indiretamente. Muitas vezes, podemos nem mesmo saber quem são as 
pessoas externas a exercerem essa influência porque ouvimos falar delas 
somente por terceiros. 


Podem ser pessoas da área contábil e financeira, de TI, do serviço de 
atendimento ao consumidor ou de RH, dependendo do tipo de aplicativo 
que você estiver desenvolvendo. Podem ser pessoas externas à empresa 


também: um(a) esposo(a), um(a) amigo(a) ou um colega de um executivo 
que exerça influência. Não é incomum que, nas reuniões, as pessoas digam 
algo como: “Eu estava mostrando o aplicativo aos meus amigos e eles 
acharam que o botão não estava suficientemente em evidência”. Então, elas 
esperam que tomemos decisões de design com base exclusivamente nessa 
pessoa anônima externa à empresa. Pior ainda é um influenciador externo 
considerado como parte da base de usuários do produto. “Eu estava 
mostrando o aplicativo para minha esposa porque ela faz parte do nosso 
público-alvo, e ela não gostou nem um pouco da visão de tabela!” Sem 
dúvida, não é um desafio insignificante. 


O que os stakeholders valorizam 


Dou o melhor de mim para ver as pessoas em diferentes funções como 
pessoas únicas e evito criar estereótipos em minha mente com base em seus 
cargos. Cada indivíduo é único, e você deve considerá-los de formas 
diferentes, independentemente de suas funções. Embora isso seja verdade, o 
ponto de vista de nossos stakeholders sobre o nosso projeto ainda é bastante 
influenciado pelo modo como eles gastam seu tempo e energia todos os 
dias. Na medida do possível, vamos analisar algumas das funções mais 
comuns na equipe, o que as pessoas nessas funções valorizam e o que isso 
significa para a nossa abordagem. Esse é somente um ponto de partida para 
ajudar você a entender como diferentes funções afetarão o ponto de vista 
das pessoas sobre o seu projeto, e em que você pode se concentrar quando 
trabalhar com elas. 
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Faça o download dessa planilha a partir de: Attp://tomgreever.com/resources 


Executivos ou gerentes 


Não é exagero dizer que os executivos e gerentes de níveis mais altos têm 
que lidar com muitas tarefas. Contudo, é mais uma questão de capacidade 
da mente do que de estar ocupado demais; eles alternam constantemente 
entre assuntos, projetos e desafios totalmente distintos. Entrar em sua 
reunião pode até mesmo desorientá-los caso não consigam se lembrar do 
ponto em que vocês haviam parado. Seu trabalho é deixá-los sintonizados o 
mais rápido possível, apresentar suas soluções e pedir que deem feedback. 
Eles querem ver que você pensou na solução e tomou decisões inteligentes, 
que se alinham à visão que eles têm da empresa. 


Pelo fato de eles valorizarem...| Você deve se concentrar em... 


Pelo fato de eles valorizarem...| Você deve se concentrar em... 


* Informações concisas e Ir direto ao ponto 


e Crescimento dos negócios * Atingir os objetivos 


* Resolução de problemas * Descrever a solução 


Desenvolvedores ou engenheiros 


Trabalhar com desenvolvedores pode ser um dos relacionamentos mais 
desafiadores para os designers; apesar disso, os desenvolvedores também 
podem ser nossos melhores aliados. Pelo fato de eles pensarem de modo 
muito diferente sobre nossos projetos, temos a oportunidade de promover 
um alinhamento com eles, o que nos ajuda a obter mais apoio de outras 
partes da empresa. 


Em geral, os desenvolvedores se preocupam com um acúmulo de bugs e 
melhorias, por um lado, e com as direções para futuros desenvolvimentos, 
com tarefas maiores do que eles conseguem administrar, por outro. Eles 
tendem a ser mais analíticos; portanto, nem chegam a “ver” alguns dos 
detalhes de UI cujo design você fez. Os desenvolvedores podem até mesmo 
se preocupar com o “excesso de design” de algo para o qual eles acham que 
o esforço extra não compensa. Seu trabalho é ajudá-los a ver a importância 
de tudo que você fizer, de modo que eles fiquem empolgados com o 
resultado, ao mesmo tempo que você mostra que compreende os esforços 
envolvidos. 


Pelo fato de eles valorizarem... Você deve se concentrar em... 


e Desenvolver uma só vez e minimizar o e Entender todos os casos de uso de antemão 


retrabalho * Maximizar o escopo existente e reutilizar padrões 


* À eficiência e um código possível de ser de UI 
mantido 


* Explicar a importância para os usuários ou os 
* À compreensão do esforço envolvido negócios 


Donos de produto 


Se sua empresa é suficientemente grande a ponto de ter um dono de produto 
(product owner) dedicado, trabalhar com ele será uma de suas principais 
tarefas. A boa notícia é que os donos de produto tendem a querer que seus 
produtos sejam os melhores possíveis; portanto, em geral, eles serão um de 
nossos maiores aliados e ficarão realmente empolgados com as soluções 


que propusermos. Receber instruções de um dono de produto, porém, é 
desafiador, se ele não tiver um bom entendimento sobre design ou do que é 
tecnicamente possível fazer, ou se não tiver uma visão muito clara dos 
planos para o produto. 


Pelo fato de eles valorizarem... Você deve se concentrar em... 


* Inovação e criatividade * Identificar novas abordagens para resolver 


* Atendimento dos objetivos de negócios problemas 


* Associar seus designs aos objetivos de negócios 


* O quadro geral, isto é, a direção no longo 
prazo * Como seu design os fará seguir em frente 


Gerentes de projeto 


A maioria dos projetos terá um gerente de projeto, mesmo que seja por 
meio de uma combinação de pessoas com diferentes funções. Essa é a 
pessoa responsável por garantir que o projeto esteja sob controle, dentro do 
orçamento e do prazo previstos. Os gerentes de projeto estão acostumados a 
pensar em diagramas de Gantt, prazos e cronogramas de entrega. Seu 
trabalho com os PMs (Project Managers) é garantir que eles sempre saibam 
em que ponto do processo vocês estão, alertá-los sobre quaisquer problemas 
o mais rápido possível e permitir que eles negociem com todas as outras 
pessoas para que o trabalho seja feito. 


Pelo fato de eles valorizarem... Você deve se concentrar em... 


* Prazos de entrega e obedecer ao * Possíveis ganhos de eficiência ao reutilizar elementos 
cronograma de design 


* Gerenciamento de escopo e de * Gerenciar expectativas acerca de qualquer mudança 
orçamentos 


* Atualizá-los quanto ao seu progresso 
* Manter todos informados 


Profissionais de marketing, conteúdo e criação 


Detesto colocar essas três funções na mesma categoria, mas há muita 
sobreposição em suas funções do ponto de vista de um designer. Algumas 
dessas pessoas, como os estrategistas de conteúdo, podem estar em nossas 
equipes multifuncionais. A questão, para os designers, é que há pessoas que 
estarão mais preocupadas com o conteúdo, a aparência e a copy! de seu 
aplicativo. Pode haver diretrizes para marcas, guias de estilo ou uma 
linguagem de design definida que oriente a maior parte dessas conversas. 


Seu trabalho é estar ciente desses requisitos, descobrir qual é o conteúdo ou 
a copy aprovados e incorporá-los em seus designs o mais cedo possível. 


Pelo fato de eles valorizarem... Você deve se concentrar em... 


* Consistência da marca por toda a * Criar estilos condizentes com a marca ou informar 
empresa qualquer diferença 


* Uma voz consistente na copy e nas e Garantir que a copy que você usar já esteja aprovada 
mensagens ou, se houver divergências, explicar por quê 


* Criação de um produto que agregue * Proposta inovadora específica para funcionalidades ou 
valor aos clientes e seja vendável microinterações 


Histórias para seus stakeholders 


Escrever histórias de usuários é um método popular usado pelos designers e 
desenvolvedores para entender seus usuários, mas você já escreveu uma 
história como essa para seus stakeholders? À medida que procuramos 
entender as pessoas com quem trabalhamos, talvez seja conveniente 
escrever histórias para que possamos entender o projeto do ponto de vista 
delas. Eis alguns exemplos para você começar: 


Executivos 


e Como executivo, gostaria de saber em que minha equipe está 
trabalhando para que eu possa apresentar um relatório à gerência de 
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e Como executivo, gostaria de dar feedback sobre o design de meus 
produtos para que eu possa ajudar você a melhorá-los. 


* Como executivo, gostaria de apresentar uma visão e os planos para o 
futuro para que minha equipe possa se sentir empolgada ao saber a 
direção para a qual estamos seguindo. 


Desenvolvedores 
* Como desenvolvedor, gostaria de criar um aplicativo sólido para que eu 
possa ter orgulho do meu trabalho. 


* Como desenvolvedor, gostaria de escrever um código de qualidade para 
que eu não precise lidar com tantos bugs nem com muita manutenção. 


e Como desenvolvedor, gostaria de conhecer todos os requisitos com 


antecedência para que eu possa planejar o meu trabalho e aproveitar 
melhor o meu tempo. 


Donos de produto 


* Como dono de produto, gostaria de criar o melhor produto possível para 
que eu possa agregar valor aos nossos clientes e à empresa. 


* Como dono de produto, gostaria de apresentar ideias novas e criativas 
para que eu possa causar uma boa impressão na empresa com a minha 
liderança. 


* Como dono de produto, gostaria de criar um produto que seja simples e 
elegante, de modo que as pessoas queiram usá-lo. 


Gerentes de projeto 


* Como gerente de projeto, gostaria de me reunir com todos da equipe 
para que eu possa garantir que tudo está sob controle. 


e Como gerente de projeto, gostaria de reduzir o escopo para que 
possamos cumprir o cronograma e continuar dentro do orçamento. 


* Como gerente de projeto, gostaria de fazer um planejamento cuidadoso 
para que eu possa garantir que teremos o tempo e os recursos 
necessários para sermos bem-sucedidos. 


Profissionais de marketing, conteúdo e criação 


* Como profissional de marketing, gostaria de dar feedback sobre o design 
do produto para que tenhamos um produto que seja competitivo e vá 
vender. 


e Como estrategista de marca ou de conteúdo, gostaria de garantir que 
todos os nossos produtos tenham o mesmo aspecto ou utilizem o mesmo 
tom, de modo que nossos clientes tenham uma experiência consistente, 
que permeie toda a empresa. 

e Como diretor de criação, gostaria de estar envolvido no design de seu 
projeto para que eu possa garantir que ele esteja alinhado com todas as 
demais iniciativas supervisionadas por mim. 

São exemplos simples para mostrar que cada pessoa em nossa equipe tem 
um ponto de vista diferente, e devemos fazer o que estiver ao nosso alcance 


para compreendê-las. Sua equipe pode empregar outras abordagens, como a 
metodologia “Jobs to Be Done” ou personas. Você também poderia criar um 
mapa de empatia ou fazer uma análise de stakeholder para adquirir uma 
compreensão mais madura das pessoas com quem você trabalha. A 
ferramenta ou abordagem exata que você vai usar é menos importante do 
que a importância de tentar entender os pontos de vista dos stakeholders. 
Quanto mais pudermos fazer para conhecer a mentalidade deles, mais 
competentes seremos para lhes apresentar nossas decisões de design de 
forma articulada. 


Mapa da empatia 


Diz Pensa 


Stakeholder 
Faz Sente 


Criar um mapa de empatia para um stakeholder é outra ferramenta importante para entender o ponto 
de vista dele. 


Muita 


Entenda Envolva 
Mantenha satisfeito Gerencie de perto 
E, 
ty 
ms 
«q 
= 
[rem 
& 
Monitore Considere 
Informe ocasionalmente Mantenha informado 
É 
É 
Pouco Muito 
Interesse 


Classifique seus stakeholders de acordo com a influência deles na empresa e o interesse em seu 
projeto. Isso pode ajudar você a saber como envolvê-los. 


Faça o download desses templates a partir de: htip://tomgreever.com/resources 


Construa bons relacionamentos 


A lição geral é esta: a comunicação se torna muito mais fácil com bons 
relacionamentos. Bons relacionamentos exigem trabalho. Com efeito, 
construir bons relacionamentos é um processo bem básico e simples: você 
obtém dele aquilo que investe. Assim, vamos ver algumas atitudes práticas 
que você pode tomar para melhorar a qualidade de seus relacionamentos 
com os stakeholders. 


A tecnologia aumentou a rapidez com que conseguimos nos comunicar, mas 
não necessariamente a qualidade da comunicação. Ferramentas para troca 
de mensagens são extremamente convenientes para trabalhar, mas 
precisamos ter cuidado para não limitar nossa comunicação somente a 
mensagens curtas. Embora, ocasionalmente, seja necessário enviar uma 
resposta rápida, não deixe que essa seja a única forma de as pessoas 
interagirem com você. Sempre que for possível, procure as pessoas para ter 
uma conversa amigável e casual. Isso exige um esforço mais deliberado 


quando trabalhamos remotamente, mas não é difícil. Use o tempo para 
tarefas simples, que ajudarão você a melhorar seus relacionamentos e, como 
consequência, a sua comunicação com outras pessoas. 


Seja você mesmo 


O melhor conselho que posso dar a você é simplesmente ser você mesmo 
quando estiver no meio de outras pessoas. Com muita frequência, as 
pessoas são sérias quando fazem trabalhos sérios. Em uma tentativa de ser 
profissional, algumas pessoas (talvez você) jamais permitem que alguém 
veja quem elas realmente são. Podemos colocar barreiras, jamais baixar a 
guarda e sempre manter o foco no trabalho, trabalho, trabalho. Essa não é a 
maneira certa de manter uma conexão com nossos chefes e colegas de 
trabalho. Você precisa mostrar às pessoas que é um ser humano e revelar a 
sua própria personalidade quando for apropriado. Sem dúvida, há ocasiões 
em que temos de colocar nosso chapéu de profissional e fazer o nosso 
trabalho, mas haverá também ocasiões nesse meio-tempo, intervalos para 
descanso e pausas para um café, em que podemos aprender a sermos 
humanos com aqueles que nos cercam. Encontrar esse equilíbrio é 
importante, as pessoas apreciam quando conseguem ver o seu “verdadeiro” 
eu. 


Faça algo para as pessoas 


Também é importante fazer algo para outras pessoas para que elas se sintam 
valorizadas. Praticamente tudo que você fizer que estiver fora do modo 
habitual como sua equipe se comunica e se relaciona causará alguma 
impressão nas pessoas com quem você se importa. Em geral, isso consiste 
apenas em falar com as pessoas regularmente para saber como elas estão. 
Você pode parar um instante na mesa delas, convidá-las para um café ou 
deixar um recado. Às vezes, apenas dizer “oi” para alguém sem nenhum 
motivo específico será suficiente para expressar isso. Qualquer uma das 
perguntas da seção anterior será muito apropriada nesse caso, mas a ideia é 
expressar que você está na mesma equipe e se importa a ponto de perguntar. 


Quando visito o escritório de um cliente em particular, sempre paro na mesa 
de Jennifer porque gostei de trabalhar com ela em um projeto anterior. 
Raramente ela está em sua escrivaninha; portanto, deixo um recado em um 


papelzinho para ela saber que estive ali. Mais tarde, soube que ela guardava 
todos os meus recados porque gostava muito deles. Em outro cliente, às 
vezes trabalho diretamente com o CEO, portanto, sempre que estou no 
local, paro em sua sala, mesmo que não tenha agendado nada. Certa vez, ele 
participava de outra conversa, mas me acenou, interrompeu rapidamente a 
sua reunião, estendeu sua mão para me cumprimentar e agradeceu por eu 
estar ali. Em outra ocasião, eu estava lendo um artigo que me fez lembrar 
de um cliente para quem trabalhei. Apesar de não termos um projeto ativo 
em andamento, mandei o artigo para ele, e isso reacendeu uma ótima 
conversa. Quero que as pessoas saibam que estou ali para servi-las, para 
ajudá-las a fazer um trabalho melhor e fazer com que tenham sucesso no 
design de ótimos produtos. Sair de meu caminho para pôr essas ações 
simples em prática me ajuda a expressar isso a elas e facilita minha vida 
quando preciso falar com elas sobre design. 


Dê algo às pessoas 


Dando um passo além, os relacionamentos melhorarão se você mostrar um 
interesse genuíno pelas pessoas dando-lhes algo que seja útil ou 
significativo para elas. 


Notas escritas à mão 


Às vezes, eu envio notas ou cartões de agradecimento escritos à mão para 
as pessoas depois de ter trabalhado com elas. Não com frequência, mas 
ocasionalmente. Quando todas as nossas comunicações são eletrônicas, um 
cartão escrito à mão é particularmente memorável e sempre causa uma boa 
impressão. Todavia, não me entenda mal; não sou exatamente uma pessoa 
do tipo que escreve cartas, para começar. Preciso realmente me esforçar 
para me lembrar de fazer isso, mas sempre acho importante e, 
provavelmente, não faço o bastante. Se você tem problemas com algo desse 
tipo, defina metas menos ambiciosas: escreva uma nota à mão para um 
cliente ou um stakeholder a cada dois ou três meses. Crie lembretes no 
calendário com uma agenda recorrente. Espero que isso ajude você a definir 
um padrão para se manter conectado com as pessoas com quem você tem o 
privilégio de trabalhar. 


Presentes simples, que não sejam caros 


Outra forma de construir relacionamentos é enviar presentes simples para as 
pessoas quando for apropriado. Não são presentes para subornar, mas são 
apenas pequenos símbolos de apreciação para mostrar que você se importa 
com as outras pessoas. Algumas empresas têm políticas quanto a dar 
presentes; portanto, certifique-se de que você conheça o ambiente e sempre 
faça uso do bom senso. Como regra, porém, dar um pequeno presente é 
uma ótima maneira de mostrar para a outra pessoa que você é mais do que 
um simples defensor de mockups. 


Para as pessoas, os melhores presentes são aqueles que mostram que você 
as ouve. Um de meus colegas tinha como hobby a fotografia; desse modo, 
dei a ele uma caneca de café que se parecia com a lente de uma câmera. 
Para meu cliente que é piloto, enviei-lhe um quadro em forma de placa de 
automóvel em que se lia “Meu outro carro é um avião” — até hoje, ele fala 
dessa placa e me convidou para voar com ele da próxima vez que eu estiver 
em Nova York. Dei um livro de humor a um colega de trabalho que estava 
prestes a se casar, cujo tema era o que os solteiros devem saber antes de se 
casar. E minha chefe, que tinha reputação de sempre pedir uísque com água, 
simplesmente ganhou isso. Comprei uma garrafa de cada, desenhei um 
rótulo personalizado para o pacote em que se lia “O de sempre de Joan” e 
pedi a uma amiga que embrulhasse tudo junto de modo que parecesse um 
produto de verdade. Foram maneiras simples, que não custaram muito, para 
fazer com que a outra pessoa soubesse que eu a valorizo. Os presentes eram 
personalizados de acordo com algo específico que eu sabia sobre essas 
pessoas. O sentimento não estava no presente propriamente dito, mas no 
que eu havia pensado ao escolhê-lo. 


Se você estiver preocupado em demonstrar favoritismo, ou não é bom em 
dar presentes individuais, uma alternativa é ser aquela pessoa que traz algo 
para todos, por exemplo, um lanchinho. Se a equipe reclamar de uma 
reunião logo cedo, traga o café da manhã. Você também pode colocar um 
pote de balas comunitário em sua mesa para dar motivo às pessoas para 
pararem por ali. Ofereça-se para uma rodada de café durante o intervalo da 
tarde. Essa forma de dar presentes não favorece um relacionamento em 
particular, mas ainda mostra às pessoas que você as valoriza. 


Pode parecer que manter o foco nos relacionamentos com os stakeholders 


não tem nenhuma relação com design. Muitos designers esperam que seus 
designs falem por si mesmos, particularmente porque se relacionam com a 
experiência dos usuários. “Se seus designs exigem uma explicação, é sinal 
de que não são muito bons.” Como se você pudesse esperar que bastaria 
entregar alguns mockups aos seus stakeholders e esperar que eles deem seu 
selo de aprovação. É surpreendente, porém, como um bom relacionamento 
pode afetar a visão de outra pessoa sobre o nosso trabalho. Ter bons 
relacionamentos realmente faz com que nossos designs sejam mais 
aceitáveis às pessoas que importam. 


As pessoas podem nos ver pela utilidade que temos, sobretudo aquela 
relacionada às nossas funções como designers. De fato, estamos fazendo 
algo do qual elas precisam, e elas poderiam, involuntariamente, ver nossas 
interações como mecânicas. Não seria nada mais que uma troca de 
habilidades. Apesar disso, quanto mais pudermos mostrar a elas que nós 
também somos seres humanos, mais importância e crédito elas darão às 
nossas ideias, sugestões e propostas. Não somos robôs trabalhando somente 
para receber um salário; somos pessoas inteligentes, com ótimas ideias, 
trabalhando juntas para criar ótimos produtos. Manter o foco nesses 
relacionamentos é mais do que apenas ser gentil e garantir que as pessoas 
gostem de nós. É lembrá-las de que somos seres humanos também e elas 
podem confiar em nós para a criação de ótimas soluções. Ter bons 
relacionamentos ajudará a garantir que isso aconteça. 


Stakeholders também são pessoas 


Se realmente esperamos nos comunicar de modo eficaz com nossos 
stakeholders, precisamos usar com os stakeholders as mesmas habilidades 
que empregamos para nos identificar com nossos usuários. Devemos 
compreender as pessoas com base nos cargos e nas posições em nossa 
equipe, reconhecer o que é importante para elas e nos lembrar das melhores 
maneiras de abordá-las. Parte desse processo envolve lembrar que elas são 
seres humanos, entender que há outras coisas acontecendo em suas vidas ou 
criar experiências compartilhadas de forma deliberada para que possamos 
mudar nossa visão pessoal sobre elas. Por fim, desenvolver empatia com os 
stakeholders nos leva a agir e a querer adotar uma abordagem que esteja 
voltada para eles, de modo a atender às suas necessidades em vez de 


atender às nossas. Não poderemos ter sucesso, a menos que nossos 
stakeholders também tenham sucesso. 


1 N.T.: Uma copy é um texto criativo, usado com frequência em anúncios ou em 
marketing, com o objetivo de promover uma marca ou um produto. 


2 Esse talvez seja o fator mais comum para determinar as reações de nossos 


stakeholders ao nosso trabalho. Eles simplesmente precisam falar dele para outras 
pessoas! 


[3] 


Planeje a reunião 


À reunião 
Fazer o 


Entender Ouvir Responder follow-up 


o —=—— os 


Ah, reuniões! Quer você as ame ou as odeie, elas fazem parte do nosso 
trabalho. Sem dúvida, em algumas empresas, há reuniões de mais, a ponto 
de ser improdutivas. Outras empresas se esforçam bastante para evitá-las, 
pelos motivos certos. Chame-as de discussões, sessões ou one-on-ones (um 
a um) se quiser. Qualquer que seja o contexto, as pessoas fazem reuniões. 
Algumas reuniões acontecem pessoalmente, enquanto outras são remotas. 
Não importa se é uma apresentação em uma grande sala de reuniões ou se é 
um simples bate-papo no café para discutir seu trabalho. Os princípios são 
os mesmos, independentemente do ambiente, das ferramentas ou da 
fidelidade da conversa. 


Pense nas reuniões como você pensaria no design de uma interface para 
executar uma tarefa. Fazer os usuários concluírem uma tarefa depende 
parcialmente de esses usuários terem uma capacidade mental disponível, 
isto é, depende de sua carga cognitiva. Quanto mais itens desnecessários, 
opções ou obstáculos colocarmos diante deles, mais difícil será executar a 
tarefa. O mesmo acontece nas reuniões com os stakeholders. Devemos 
tentar eliminar o máximo possível os itens desnecessários, as opções ou os 
obstáculos para que as mentes de nossos stakeholders estejam livres, 
permitindo que se concentrem na principal tarefa da reunião: dar apoio às 
nossas decisões de design. Para isso, precisamos planejar melhor nossas 
reuniões de design. 


Se os stakeholders estiverem distraídos com um mockup antigo, não 
tiverem clareza quanto ao objetivo ou, simplesmente, não conseguirem 
deixar de pensar na última reunião em que estiveram, será muito mais 
difícil obter o apoio deles. Nosso objetivo não é somente fazer uma reunião, 
mas torná-la produtiva, valiosa e bem-sucedida. Para isso, precisamos 


deixar que nossas reuniões sejam mais “usáveis” e, até mesmo, prazerosas. 


Este capítulo descreve como definir o contexto apropriado, fazer 
otimizações para facilitar a memorização, eliminar as distrações da 
conversa, antecipar o que os stakeholders poderiam dizer e levar outras 
pessoas que possam nos ajudar na reunião. Além disso, devemos fazer um 
trabalho adequado de preparação para essas discussões. Nosso objetivo é 
planejar uma reunião que reduza a carga cognitiva de nossos stakeholders, 
de nossa equipe e de nós mesmos. 


Defina o contexto 


Uma maneira de facilitar as reuniões para os stakeholders é definir o 
contexto no início. Isso significa começar a reunião relembrando o objetivo 
do projeto ou do design em questão, em que ponto do processo estamos e os 
tipos de feedback que esperamos que eles nos deem. Também devemos 
deixar claro que o propósito da reunião é obter o apoio deles para que o 
projeto avance, e não necessariamente que eles façam comentários sobre 
tudo que virem. 


Os executivos podem ter dificuldade em mudar o foco para o nosso projeto 
quando saem de uma reunião para outra. Embora possamos passar o dia 
inteiro pensando em nossos problemas, isso poderia não ser possível para 
eles; para os stakeholders, talvez seja extremamente difícil se lembrar do 
motivo de estarem em nossa reunião, caso tenham várias reuniões ao dia, 
todas sobre produtos ou designs totalmente distintos. Esse é um desafio 
comum para os nossos stakeholders, mas podemos ajudá-los. 


Eis algumas dicas para deixá-los rapidamente em sintonia com a reunião: 


Defina o objetivo 

O primeiro ponto que você deve fazer com que eles se recordem é o 
objetivo acordado anteriormente para esse projeto ou design. O ideal é 
que seja uma métrica melhorada para os negócios ou o resultado que 
esperamos obter, mas o objetivo pode ser definido também como a 
funcionalidade ou a saída de seu trabalho. Também pode ser sua resposta 
à pergunta: Qual é o problema que isso resolve? Qualquer que seja o objetivo, 
exponha-o claramente logo no início, antes de começar a discutir seus 
designs. 


Faça um resumo da última reunião 
Em segundo lugar, lembre-os rapidamente da discussão que vocês tiveram 
da última vez ou das decisões que tomaram juntos. Pode ser uma frase 
curta ou vários itens, dependendo do projeto. Qualquer que seja o caso, 
você deve refrescar rapidamente a memória dos stakeholders acerca de 
sua última conversa. 


Mostre uma linha do tempo 

Em seguida, utilize um recurso visual que os ajudará a entender em que 
ponto do processo você está em seu design. Em geral, essa informação 
pode ser expressa como uma linha horizontal na qual o lado esquerdo é o 
ponto de partida (pesquisa, mockups com baixa fidelidade), e o lado 
direito é o design concluído (alta fidelidade, pronto para ser lançado). Dê 
ênfase ao ponto em que você está nesse espectro e no nível de fidelidade 
que eles podem esperar ver nos designs. 


Especifique o tipo de feedback de que você precisa 

Além disso, diga a eles quais são os tipos de feedback que são úteis nessa 
etapa do projeto e quais são aqueles que ainda não são necessários. Por 
exemplo, você poderia esperar um feedback sobre o layout e o conceito 
em geral, mas é cedo demais para que eles façam comentários sobre uma 
cópia de texto específica ou as cores. Ajudá-los a entender o tipo de 
feedback que é mais importante ajudará você a direcionar a conversa de 
um modo mais produtivo. 


Declare, novamente, qual é o objetivo 
Por fim, declare novamente qual é o objetivo. É importante que haja um 
consenso entre todos quanto ao problema que está sendo resolvido. As 
conversas perdem o foco quando as pessoas não se lembram do objetivo, 
ou se o objetivo mudar sem que tenhamos percebido. Repetir qual é o 
objetivo o reforçará e ajudará todos a se lembrarem do que vieram fazer 
na reunião. 


Onde estamos? 


Esboços Wireframes Mockups Designs de alta fidelidade Interação Protótipo 


e 


Aspectos mais importantes 
º Layout geral 
e Fluxo do usuário, passos 
“Como funciona (ou não!) 
* Componente de serviço 
* Possivel impacto no objetivo 


Exibir uma linha do tempo horizontal que represente o ponto em que você está no processo é muito 
conveniente para definir o contexto da discussão. 


Escolha a receita 


Compre os ingredientes 


O que precisamos: 
Prepare a massa e Orientação ou aprovação para a marca 
e Feedback ou aprovação legal 
e Fotografias ou fotos de perfis associadas 
e Conteúdo ou cópias de texto específicos 


Asse o bolo 


Coloque a cobertura 


ES Sirva! 


Uma equipe me disse que usava a metáfora de fazer um bolo para ajudar seus stakeholders a saberem 
em que ponto do processo eles estavam. 


Estado atual 


v 


A representação não precisa ser linear nem apresentar um fim. Crie uma imagem que melhor 
represente o processo de sua própria equipe para ajudar as pessoas a saberem em que ponto você está. 
Definir o contexto não precisa ser uma tarefa que consuma muito tempo. 
Pode ser feito com algumas frases curtas ou com um único slide. Em 
revisões de design menos formais, eu procuro listar pelo menos alguns itens 
para mim mesmo a fim de definir o contexto. Em apresentações oficiais, que 
envolvam mais pessoas, posso incluir até três slides específicos para isso. A 
prioridade é garantir que as pessoas com quem estou falando entendam por 
que estamos na reunião em questão, para que possamos ter uma conversa 
produtiva. 


Dê nome à reunião 


Uma maneira simples para ajudar a definir o contexto aos stakeholders é dar um 
título apropriado aos convites para a reunião no calendário. Pense no calendário de 
seu stakeholder, repleto de convites ostentando o seu próprio nome ou “Revisão de 
design”. Você não vai querer que eles apareçam e perguntem logo de cara: “De que 
se trata essa reunião?”. O convite no calendário deve ajudá-los a saber o que 
esperar. 


Em vez disso, inclua o seu próprio nome ou o nome da equipe, mais o nome do 
produto, do projeto ou da parte da interface que você vai apresentar. Você também 
deve informar o conteúdo da reunião sem implicar que o propósito seja 
exclusivamente que eles deem feedback. 


Por exemplo, eu envio convites de calendário como estes: 

e Tom Greever, Estudo de Caso de UX 

* Design do home services + recepção 

* Pesquisa de UX: insights sobre buscas 

* Conteúdo da página inicial, equipe de UX 

Acho que palavras como revisão, sincronização, demo, feedback ou discussão são 
desnecessárias porque estão implicadas, assim como chamar de “reunião”. Se os 
stakeholders vão participar de uma reunião conosco sobre design, é provável que 


eles suponham que seja uma dessas versões. Resista ao impulso de incluir esses 
descritores. 


Por fim, inclua algumas informações úteis no corpo do convite também. Um 
resumo executivo do que será discutido, a agenda e, talvez, links para outros 
documentos ou componentes do design. Desse modo, quando estiverem se 
preparando para o dia da reunião, eles terão à disposição tudo de que precisarem 
de nós, sem que seja necessário sair em busca dessas informações. Isso não só os 
deixará satisfeitos, como também fará com que o nosso tempo com eles seja mais 
produtivo. 


Otimize para facilitar a memorização 


Planejar melhor uma reunião também significa entender como nossas 
mentes funcionam e fazer otimizações para garantir que nossos stakeholders 
se lembrem do que foi discutido. A seguir, apresentarei alguns conceitos 
simples que podemos ter em mente. 


Primazia e recência 


Os princípios de primazia e recência ao ouvir e memorizar nos dizem que é 
mais provável que as pessoas se lembrem da primeira e da última coisa que 
dissermos. Elas perdem totalmente a concentração em algum ponto nesse 
intervalo. Podemos usar esse fato em nosso favor separando nosso 
conteúdo em partes significativas (menores) e criando transições distintas 
entre cada parte. Isso faz com que seja mais provável que nossos 
stakeholders se lembrem mais da conversa porque ela será registrada como 
uma série de miniconversas, em vez de uma longa reunião. 


Atenção 


A Curva do esquecimentã 


Duração da reunião 


E com divisão em partes E] sem divisão em partes 


Se sua apresentação for uma fala longa (em azul), será difícil para as pessoas prestarem atenção. Ao 
dividir seu conteúdo (em vermelho), você criará mais oportunidades para as pessoas se lembrarem. 
Uma maneira comum de fazer isso é criar itens distintos na agenda e tomar 
decisões claras para cada um, expressando verbalmente o momento de 
passar para o próximo item. No entanto, tenho constatado que outras 
abordagens concomitantes também podem ser empregadas. Usar pistas 
visuais adicionais ou quebrar a monotonia com movimentos também pode 
ajudar. Você poderia mudar a cor de fundo de seus slides ao passar de uma 
parte para outra. A diferença proporciona uma separação visual clara. Você 
também pode fazer uma pausa, ficar em pé e se alongar, fazer as pessoas 
mudarem de lugar ou distribuir algo para comer. Há várias maneiras de criar 
uma distinção clara entre as partes. 


Objetivo: melhorar a razão entre macaco 


e gatinho na página inicial. 


Usei interfaces com abas e uma navegação por pontos em meus slides para ajudar as pessoas a 
saberem em que ponto da apresentação estamos, bem como para fazer uma distinção clara entre cada 
parte ou decisão. 


Repetição 

É mais provável que as pessoas se lembrem de algo que tenha sido repetido. 
Essa sabedoria universal, usada em marketing e na publicidade, também 
será útil nas discussões com nossos stakeholders. Quais são os pontos mais 
importantes que você quer que eles se lembrem? São o objetivo ou o 
problema que estamos tentando resolver e a decisão que tomamos. Assim, 
planeje repetir essas informações (verbalmente, ou de modo visual com um 
slide) pelo menos três vezes durante a conversa. É mais provável que as 
pessoas se lembrem de algo que tenha sido repetido. 


Surpresa 


E mais provável também que as pessoas se lembrem de algo que não 
estavam esperando. Se você conseguir achar uma forma de inserir algo em 
sua discussão que, habitualmente, não faça parte de suas reuniões, as 
pessoas se lembrarão. Pode ser difícil fazer isso em um ambiente de 
negócios, no qual se espera que tudo seja muito profissional; tenho 
constatado, porém, que um toque de leveza, o uso de humor para quebrar o 
gelo ou surpresas inesperadas podem ser eficazes. A técnica mais simples é 
uma piada oportuna que interrompa uma conversa estagnada. Lembre-se de 
que a questão não é somente surpreender as pessoas somente pela surpresa 


em si, mas ajudá-las a se lembrar de um conteúdo importante. Eis algumas 
ações que já coloquei em prática: 
e Já usei imagens de animais bonitinhos (em geral, de gatinhos) em um 
slide, junto de algum dado, o objetivo ou o cronograma/prazo de 
entrega. 


* Conduzi uma reunião inteira como se fosse um jogo de perguntas no 
qual cada stakeholder escolhia a categoria que determinava a parte do 
projeto que iríamos discutir. Para ser franco, não acho que tenham 
gostado muito da ideia — eles pareciam estar entediados —, mas acredito 
que, apesar de tudo, foi eficaz porque cada stakeholder teve de ler 
aquela parte do projeto em voz alta. 


e Certa vez, imprimi o nosso objetivo em uma folha de papel, junto a 
várias mensagens do tipo que vemos em biscoitos chineses da sorte, e 
preguei-a na parte de baixo de suas cadeiras. Iniciei a reunião pedindo a 
todos que olhassem embaixo de suas cadeiras e lessem as mensagens. 


Aposto que você não estava esperando ver um tubarão neste livro, mas eu o coloquei aqui para que 


você se lembre de que um elemento-surpresa é muito eficaz 2 


O desafio ao usar um elemento-surpresa é que você não quer que ele se 
transforme em uma distração. Conforme veremos mais adiante, parte do 
nosso trabalho é eliminar as distrações. Portanto, encontre o equilíbrio 
adequado para manter as pessoas interessadas em seu conteúdo, sem causar 
distrações desnecessárias que atrapalhem a reunião. 


Mídias diferentes 


Cada pessoa também aprende e retém informações de formas distintas. 
Algumas pessoas processam verbalmente as informações e precisam dizê- 
las para si mesmas. Outras precisam ouvir as informações serem proferidas 
em voz alta. Outras ainda necessitam que elas sejam apresentadas 
visualmente. Como você investiu tempo para entender seus stakeholders, 
talvez já tenha um palpite sobre as melhores maneiras de se comunicar com 
eles. Recomendo usar diversos métodos para descobrir o que funciona. 
Utilizar uma combinação de descrições verbais, apresentações visuais 
(slides) e informações por escrito ou impressas abrange a maioria dos casos 
de uso. 


Já trabalhei com um executivo que parecia preferir documentos em páginas 
wiki, com níveis de cabeçalho apropriados e listas com itens. Era 
simplesmente o formato com o qual ele estava habituado e que o deixava à 
vontade. Em outra empresa, o CEO respondia melhor quando tudo estava 
em um conjunto de slides — mesmo que fosse em uma conversa informal. 
Percebi que, se eu colocasse minhas palavras em um slide padrão da 
empresa, ele parecia ficar mais receptivo. Descubra as formas corretas de 
conquistar seus stakeholders a fim de aumentar as chances de eles se 
lembrarem das decisões que vocês tomaram juntos. 


Elimine as distrações 


Manter a concentração em uma reunião de design é essencial. É muito fácil 
as discussões se desviarem ou tomarem uma direção inesperada por causa 
de um pequeno detalhe. Quando o assunto é design, simplesmente há algo 
nessa disciplina que suscita muito mais conversas tumultuadas do que em 
outras áreas. Uma maneira de manter o foco é eliminar qualquer item que 
você considere que causará distrações. Muitas pessoas se distraem 
facilmente com questões que simplesmente não são importantes para o 
objetivo da reunião. Elas podem se distrair bastante com um detalhe, a 
ponto de poderem identificar um problema diferente, sem relação com o 
objetivo da reunião, ou de se tornarem incapazes de discutir os verdadeiros 
problemas. Assim, parte de seu trabalho é prestar atenção nesses pontos e 
eliminá-los da conversa. 


Um exemplo comum envolve o uso de um conteúdo placeholder: imagens 


de banco de dados e cópia lorem ipsum. Nem consigo enumerar a quantidade 
de vezes que meus clientes ficaram obcecados com o conteúdo placeholder 
que eu havia escolhido. Eis alguns exemplos: 


* Eu estava fazendo o design de um site para uma fabricante de motores 
automobilísticos e havia selecionado a imagem de um produto para ser 
usada na página inicial. O cliente passou uma quantidade absurda de 
tempo falando que aquele motor em particular não era o melhor produto 
que eles tinham para vender e, com efeito, estava sendo descontinuado 
por causa de falhas no projeto. Em seguida, ele passou a me dar uma 
aula sobre toda a linha de motores da empresa. 


* Eu estava trabalhando para uma rede de varejo que não tinha nenhuma 
imagem prontamente disponível do interior de suas lojas; assim, 
encontrei uma imagem online para ser usada como placeholder e a incluí 
nos mockups. Por acaso, eu havia escolhido uma foto de seu principal 
concorrente. Foi difícil para o stakeholder ignorar o fato de que ele 
estava olhando para o concorrente em um mockup do site de sua própria 
loja. 

* Em um aplicativo de mapeamento, utilizei uma tela do Google Maps 
como placeholder para o plano de fundo, no lugar em que o mapa 
deveria estar. Meu cliente usava um provedor de serviço de mapeamento 
diferente e teve dificuldade para lidar com o fato de que a imagem não 
se parecia com os mapas que seriam vistos no aplicativo real. 


* Em um aplicativo para uma empresa farmacêutica, minha cliente ficou 
confusa com o fato de não poder entender a cópia ipsum, apesar de ter 
estudado latim na faculdade. Ela passou parte da reunião tentando ler o 
texto em voz alta, e eu tive de explicar para ela o motivo pelo qual 
usamos a cópia ipsum em design. 


Em cada um dos casos, o conteúdo que utilizei como placeholder criou uma 
distração desnecessária. 


O desafio está no fato de que eliminar essas distrações que, com frequência, 
exige mais trabalho. Usamos a cópia ipsum porque é mais fácil do que 
escrever a cópia real. Utilizamos imagens de banco de dados porque uma 
pesquisa rápida nos fornece uma infinidade de opções. Com efeito, uma 
abordagem Agile/Lean valoriza iterações rápidas, MVPs, trabalhos rápidos 


e sprints curtos. A perspectiva de ter de trabalhar mais, incluindo dois 
passos extras nos mockups, parece ser contrária a essas filosofias. Pior 
ainda, pode atrasar você, certo? Não necessariamente. 


Eu estava trabalhando com uma pessoa que era muito sensível e gostava de 
ver tudo perfeitamente alinhado na forma de tabela. Meus wireframes eram 
um pouco bagunçados porque, bem, eram apenas wireframes: um trabalho 
rápido e grosseiro, suficiente apenas para comunicar a intenção. Ele 
começou fazendo sugestões para mudar o layout: “Mova essa chamada à 
ação para cá, coloque esse elemento lá para baixo”. Não eram ajustes 
pequenos, mas um retrabalho geral. Comecei a perceber que ele se distraía 
muito com o fato de os elementos estarem desalinhados e estava tentando 
fazer com que o design parecesse mais harmonioso. Fiz uma pausa na 
discussão e voltei depois de alguns minutos, garantindo que tudo estivesse 
devidamente alinhado. Quase de imediato, seu feedback mudou. Muitas de 
suas objeções sobre o posicionamento dos elementos principais 
desapareceram. Podíamos agora manter o foco nos verdadeiros problemas. 
Contudo, aprendi que, com essa pessoa em particular, era importante que eu 
investisse tempo para organizar meus wireframes, de modo que eu pudesse 
ganhar tempo em uma reunião, bem como evitar possíveis retrabalhos. 


No entanto, a situação pode não ser tão simples quanto remover um 
conteúdo usado como placeholder ou alinhar elementos. Algumas pessoas 
realmente se distraem com qualquer uso de cor, portanto é melhor evitar 
cores. Outras se distrairão com elementos de UI legados que não são o foco 
da reunião, por exemplo, um elemento de navegação antigo que eles sabem 
que não deveria estar ali. Cada pessoa é diferente, e nosso trabalho é 
identificar essas distrações e eliminá-las. 


A essa altura, você deve avaliar se vale a pena gastar esse tempo extra para 
eliminar essas distrações quando chegar a hora de obter o apoio dos 
stakeholders. Pessoalmente, acho que vale a pena o esforço extra para 
identificar e eliminar as distrações, a fim de permitir que o projeto avance. 
Se seu cliente não perceber que há um requisito de negócios que não foi 
contemplado porque ele se distraiu com outro detalhe, esse requisito 
ausente se manifestará em algum momento no futuro — em geral, quando for 
tarde demais no processo. Faça o que for necessário para permitir que seus 
stakeholders mantenham o foco, mesmo que isso exija tempo e preparação 


adicionais. 


Uma cliente minha realmente gostava do painel à esquerda, criado pelo 
Axure quando um protótipo é gerado. É somente um iframe que lista todas 
as páginas do protótipo, isto é, um mapa de site do projeto todo 2 De fato, 
ela gostava tanto desse painel que fazia comentários sobre ele em todas as 
nossas conversas: “Ah, é tão conveniente poder ver todas as páginas logo 
ali”. Em geral, eu simplesmente ignorava essa sua paixão pelo painel e 
prosseguia com a reunião. Finalmente, durante uma conversa, ela sugeriu 
que usássemos esse painel para navegação no aplicativo. “Simplesmente 
adoro o fato de poder ver tudo o tempo todo”, disse ela. “Devemos usar 
esse painel para a nossa navegação!”. Todo o trabalho de design que 
havíamos feito, e com o qual havíamos concordado antes, para criar uma 
hierarquia consistente e significativa para o aplicativo, estava ameaçado! 
Novamente, optei por não responder naquele momento; depois disso, 
porém, comecei a entrar na estrutura de pastas do Axure e a enviar para ela 
o link direto para o arquivo HTML, que seria aberto fora do iframe para que 
ela não pudesse mais ver o painel à esquerda. Desde então, a cliente jamais 
voltou a mencioná-lo. 
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Uma de minhas clientes se distraía tanto com o painel à esquerda, gerado pelo Axure (destacado em 
vermelho na figura), a ponto de sugerir que usássemos esse painel para navegar no aplicativo cujo 
design estávamos fazendo. 

Um aplicativo cujo design eu estava fazendo precisava de um ícone para a 
conta do usuário, e nós escolhemos a silhueta de uma pessoa. O software 
que eu estava usando tinha um conjunto limitado de ícones disponíveis, e 
aquele ícone de usuário em particular se parecia realmente com bolhas — 
uma representação horrível para um usuário. Apesar disso, por uma questão 
de tempo, eu o usei como placeholder porque não achei que valesse a pena 
criar meu próprio ícone somente para esses mockups. Após a terceira 
reunião, durante a qual uma pessoa diferente mencionava o quão horrível 
era o ícone, finalmente decidi fazer um esforço extra para criar meu próprio 
ícone e eliminar esse assunto da discussão. Se eu tivesse usado um ícone 
melhor desde o princípio, poderia ter evitado a necessidade de ter de 
explicá-lo em cada ocasião. 


O ícone default usado como placeholder que estava prontamente disponível para mim (à esquerda) 
era tão ruim que estava causando distrações a todos que o viam; assim, no fim das contas, resolvi 
investir tempo para escolher um que fosse melhor (à direita), e a discussão sobre esse ícone cessou. 
A questão, nesse caso, é que, à medida que conhecer as pessoas, você será 
capaz de identificar o que faz com elas se distraram e poderá eliminar esses 
detalhes da conversa. Com muita frequência, as pessoas (sobretudo aquelas 
que não são designers) ficam obcecadas com detalhes que realmente não 
são importantes para os objetivos do site ou da aplicação. Mesmo depois 
que você as ajuda a entender que esses detalhes são temporários ou que não 
interessam, percebo que elas continuam voltando ao assunto repetidamente. 
“Sei que falamos disso da última vez, mas ainda acho que precisamos 
refazer o design desse menu.” Simplesmente elimine todas as distrações! As 
distrações devem surgir somente uma vez. Se você estiver em duas reuniões 
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e a mesma distração surgir nas duas ocasiões, é sinal de que você está 
cometendo um erro. Invista tempo para identificar as distrações e eliminá- 
las para que seja possível manter o foco nos verdadeiros problemas ligados 
à eficácia de seus designs. 


Antecipe as reações 


Com base no que você já sabe sobre as pessoas com quem estiver 
trabalhando, você deverá ser capaz de antecipar como reagirão aos seus 
designs. No capítulo anterior, identificamos as pessoas que exercem 
influência em seus projetos, o que elas valorizam e quais são suas 
motivações. Quando combinamos o que sabemos sobre o ponto de vista 
delas com o que elas valorizam em seus cargos, teremos bons palpites sobre 
como responderão aos nossos designs. A boa notícia é que a maioria das 
pessoas é razoavelmente bem previsível. Isso quer dizer que elas tendem a 
ficar obcecadas com os mesmos fatos e a reagir a eles em todas as ocasiões. 
Se você já conhece essas pessoas, prever a reação delas será muito mais 
fácil. São necessárias algumas reuniões para realmente saber como as 
pessoas agem, mas percebi que antecipar as reações é uma tarefa muito 
mais previsível do que seria esperado. 


Dicas para reuniões remotas 


A maiorias das pessoas, ao ler este livro, não percebe que eu trabalho 
remotamente, de casa, e muitas das reuniões que descrevo não ocorrem 
pessoalmente. De fato, já fiz mais reuniões de design remotas do que 
pessoalmente. Eis algumas dicas para que as reuniões remotas sejam eficazes: 


* Diga a todos que liguem suas câmeras. Mesmo que haja algumas pessoas em 
uma sala de reuniões, cada uma dessas pessoas deve utilizar o seu próprio 
notebook e a câmera, de modo que todos que participarem remotamente possam 
ver todos os demais. As pessoas se sentirão excluídas se houver alguém com a 
câmera desligada. 


* Compartilhe sua tela e seu vídeo. Você quer que todos vejam tanto o seu rosto 
como o conteúdo que você estiver apresentando. 


* Encontre um plano de fundo apropriado. O ideal é que você se sente em um 
local que tenha uma parede simples atrás e haja luz para iluminar o seu rosto. 
Não ajudará muito se todos ficarem prestando atenção no que está em sua 
estante, ou se seu rosto estiver muito escuro. Por esse motivo, tenho uma parede 
vazia, pintada de azul, atrás de minha escrivaninha, de propósito. Planos de 


fundo virtuais podem ajudar, mas, com frequência, são, igualmente, uma 
distração. 

* Seja especialista em deixar o microfone mudo. Seu microfone deve estar 
ligado somente quando você falar. Saiba qual é o atalho de teclado para deixar 
seu microfone mudo e use-o. Todas as melhores equipes remotas são 
especialistas em deixar o microfone mudo. 


* Pense em suas expressões faciais. Sorria e concorde com um gesto de cabeça, 
como faria se estivesse presente pessoalmente. Ver uma pessoa franzir o cenho 
no meio de uma reunião pode ser desanimador, mesmo que ela faça isso para 
outra pessoa. Relacionado a esse tópico, utilize a webcam conectada à tela que 
você estiver usando para que pareça que você está olhando para as pessoas que 
estão na reunião. É desalentador quando as pessoas usam vários monitores e 
parecem estar olhando para o lado. 


* Desative as notificações é Já existem distrações demais, mensagens de bate-papo 
e tentações para verificar suas curtidas nas redes sociais. Desative tudo e 
mantenha o foco nas pessoas que estão em sua reunião. 


* Atenue os riscos associados à tecnologia. Prepare-se para utilizar um telefone 
para ter áudio, além de usar o áudio do computador. Se a internet cair, você 
ainda terá o áudio. Se puder, utilize ethernet em vez de WiFi; é muito mais 
rápido e confiável. Eu utilizo inclusive um roteador dedicado para ter prioridade 
na largura de banda usada em meu escritório, de modo que o hábito de meus 
filhos de assistirem a streaming de vídeos não atrapalhe minhas reuniões. 


O gerente que fez perguntas sobre a cor que você usou pensará de forma 
mais crítica nos detalhes da UI. O desenvolvedor que queria ver a análise de 
dados do aplicativo atual valoriza o uso de dados para sustentar seus 
argumentos. O executivo que achou que a chamada para a ação não estava 
em um local suficientemente acima na página precisa saber como suas 
escolhas afetarão a conversão e as vendas. Podemos sempre esperar ouvir 
ideias, recomendações e objeções parecidas dessas pessoas. O que parece 
ser uma aptidão vaga, indistinta, na verdade, se assemelha mais a uma 
receita: personalidade + cargo / valores + reações observadas = 
comportamento previsível! Embora não seja realmente tão simples assim, 
com o tempo, passará a ser mais fácil e mais previsível. 


Assim, analise cada um de seus designs, observe a agenda da reunião e 
decida qual é o fluxo mais apropriado para apresentar suas ideias. Do 
mesmo modo que criamos um fluxo para os nossos usuários na aplicação, 
também queremos aperfeiçoar o fluxo de nossa discussão sobre o design. 


Agora associe essas necessidades às pessoas presentes na sala. Para cada 
pessoa, pergunte a si mesmo: 


* Com o que elas mais se preocupam?” 
e Quais são seus objetivos pessoais para esse design? 
* O que eu já sei sobre aquilo que elas querem ou não querem? 


Pense nos cargos específicos dessas pessoas e dê seu melhor palpite sobre 
como o ponto de vista delas pode ajudar você. Se não tiver certeza, 
pergunte diretamente o que elas esperam obter do design ou como se veem 
contribuindo com ele. Dizer às pessoas que você quer ter a certeza de que 
está aproveitando o tempo delas da melhor maneira possível é apropriado. 
Entender o envolvimento delas ajuda você a organizar a agenda e a se 
preparar para prever o modo como tudo se desenrolará. 


Anote as objeções 


Assim que você tiver considerado todas as pessoas envolvidas, anote 
quaisquer objeções que você espera que elas possam ter, junto à sua própria 
resposta. Até você realmente desenvolver a competência para responder de 
imediato, talvez seja difícil se lembrar de como você planejava responder 
quando chegar a ocasião. Faça uma lista, leia e releia várias vezes, até que 
você esteja totalmente preparado com os melhores palpites sobre como as 
pessoas reagirão aos seus designs. Mesmo se não conseguir associar cada 
reação prevista a uma única pessoa, continua sendo uma boa ideia criar uma 
lista simples de objeções que você acha que podem ser levantadas. Elas 
podem estar na forma de perguntas que poderiam ser feitas ou de opiniões 
que você acha que serão emitidas. 


Eis alguns exemplos de como você poderia anotar as objeções previstas: 


* Por que removemos uma das CTAs? | | e Por que a imagem não é maior, conforme discutimos? 


* O carrossel (carousel) avança e Temos de usar dois botões diferentes? Podemos colocar 
automaticamente? (Justin) a CTA acima do fold? 


* O utilitário de navegação está muito | e Por que Reviews (Comentários) está bem mais abaixo 
abarrotado. (Kristen) na página? 


* O que aconteceu com o feed * À interação de navegação fixa deve adicionar 
Recommended Item (Item automaticamente o item no carrinho de compras. 
Recomendado)? (Kristen) 


* Não podemos “esconder” o botão e Há casos de uso mais complicados nesse fluxo, além 
Join (Associar-se) no menu. (Mark) daqueles que eu acho que você considerou. (Mark) 


Crie alternativas 


Parte de prever o modo como as pessoas reagirão é preparar, com 
antecedência, as alternativas que você considerou ou acha que serão 
sugeridas. Você deve se lembrar, conforme vimos no Capítulo 1, que uma 
das perguntas que estamos tentando responder aos nossos stakeholders é: 
Por que essa solução é melhor que a alternativa? 


Trazer alternativas (particularmente aquelas que não são a solução 
recomendada) complica a conversa porque nos força a ter uma explicação 
bem articulada para as nossas escolhas. Muitos designers evitam isso e não 
apresentam as alternativas que não recomendariam. Há o temor de que o 
cliente prefira o conceito “errado” e insista em usá-lo. Embora sempre haja 
esse risco, abordar nossas reuniões com esse temor, na verdade, prejudicará 
nosso propósito de sermos articulados para explicar nossas decisões de 
design. Se não pudermos convencer os stakeholders de que a nossa solução 
é a melhor, é sinal de que não estamos fazendo um bom trabalho para nos 
comunicarmos com eles, ou não entendemos suas necessidades o suficiente 
para criar um design que resolva o problema. O que realmente precisamos é 
que eles apoiem a nossa solução, mesmo depois de terem considerado todas 
as alternativas. Não podemos protegê-los de todas as ideias que possam ser 
sugeridas. Em vez disso, devemos armá-los com o conhecimento e a 
linguagem necessários para explicar por que nossas decisões são as 
melhores. É a única maneira pela qual realmente conquistaremos o apoio 
dos stakeholders no longo prazo e conseguiremos a adesão deles para a 
nossa solução. 


Você vai querer ter esses designs e mockups alternativos como uma 
evidência de que tentou essas outras abordagens, entendendo por que elas 
não são tão eficazes quanto aquela que você está propondo. Por exemplo, se 
você sabe que alguém vai perguntar sobre o ícone que você escolheu, traga 
um conjunto de ícones alternativos que podem comunicar o mesmo 
conceito. Isso mostra que você pensou no assunto e escolheu aquele que 
acredita ser a melhor opção. Às vezes, o design que viemos discutir foi 
sugerido em uma reunião anterior. Os stakeholders pediram que você 
fizesse algumas mudanças (apesar de seus melhores esforços para 
convencê-los do contrário), e agora você deve mostrar esse design a eles. 
Nessas situações, trazer alternativas é, sem dúvida, essencial para 
demonstrar por que a solução proposta por você é melhor. No entanto, você 
ainda terá de iniciar a conversa com o design que eles esperam ver. Desse 
modo, apresente a ideia solicitada por eles, mas prepare também as 
alternativas que você acha que resolverão o problema de modo mais 
apropriado. 

Mais do que apenas considerar a sugestão de alguém, trazer alternativas cria 
um território comum para discutir os méritos de cada opção — um território 
que, a propósito, você criou e do qual tem o controle. Se você vier para a 
reunião sem trazer alternativas, seus stakeholders farão pesquisas na 
internet em seus celulares e proporão a primeira opção que encontrarem. 
Você poderá sustentar o seu argumento de modo muito mais sólido se tiver 
um conjunto de ideias mais bem preparadas, diante de qualquer alternativa 
que eles encontrarem em poucos segundos na internet. Não jogue fora todas 
as ideias rejeitadas; traga-as com você. Veremos como apresentar as 
alternativas novamente no Capítulo 6, mas lembre-se de que ter mais de um 
design sempre mostra que há mais de uma forma de resolver o problema em 
questão. 


Prepare dados & resultados de pesquisas 


Do mesmo modo, prepare dados ou resultados de pesquisas (análise de 
dados, relatórios de usabilidade, resultados de testes de usuário) para 
defender qualquer parte de sua proposta. Uma coisa é fazer uma sugestão, 
mas ter os dados que darão sustentação à sua solução é diferente. Na 
maioria das vezes, será suficiente deixar que todos saibam que suas 


decisões se basearam em dados e/ou pesquisas, enquanto apresenta uma 
visão geral rápida do que você constatou. Com efeito, eu não recomendo 
expor os dados, a menos que seja necessário para defender o seu argumento. 
Usar dados para fortalecer sua posição será conveniente se as pessoas 
discordarem ou reagirem aos seus designs com ceticismo. Como, nesse 
momento, você está apenas antecipando o modo como as pessoas reagirão, 
tenha as informações disponíveis, prepare-as com antecedência e lembre-se 
de que sua decisão se baseia nelas, mas não as jogue na mesa durante a sua 
apresentação. 


Dados são muito eficazes (quase eficazes demais) e podem causar um efeito 
estranho nas pessoas. Às vezes, eles criam um ambiente no qual as pessoas 
acham que não podem contribuir com nada. “Bem, se é o que dizem as 
pesquisas, é isso que devemos fazer” Você poderia inibir a conversa, 
mesmo antes que ela comece. Apesar de tudo, queremos e precisamos que 
nossos stakeholders estejam envolvidos na decisão. Na outra extremidade 
do espectro, já vi pesquisas serem menosprezadas com base na metodologia 
ou no “tamanho da amostra”. Com efeito, um “expert” bem articulado, 
expressando opiniões em suas reuniões, pode parecer ter o mesmo peso dos 
resultados de sua pesquisa. Portanto, esteja preparado para defender suas 
decisões com dados e pesquisas, mas não se sinta na necessidade de usá-los, 
a menos que sejam necessários para sustentar o seu argumento. 


Durante o tempo em que você trabalhar com os stakeholders, sua função 
será saber o que os motiva, identificar o que é importante para eles e, então, 
criar um plano para saber como você responderá para eles na reunião. 
Anotar as reações previstas, levar designs alternativos e ter dados ou 
resultados de pesquisa disponíveis são partes importantes desse processo. 
Nem sempre você conseguirá fazer isso de forma perfeita, mas essas 
atitudes ajudarão você a estar preparado. Muitas vezes, apenas saber o que 
esperar em uma reunião pode ser muito útil para que você seja articulado 
naquele momento. 


Crie uma rede de apoio 


Uma das melhores atitudes que você pode tomar para garantir que seus 
stakeholders apoiem o seu trabalho é incluir outras pessoas que também 


apoiam suas decisões. Isso significa que você deve assegurar que haja 
outras pessoas na sala que darão apoio a você, ajudarão em sua 
argumentação e inclinarão a balança em seu favor quando se tratar da 
decisão final. Você precisa de defensores para o seu design. 


Ter o apoio de outras pessoas para as suas decisões diz respeito a mostrar 
que você não está sozinho com suas ideias. Mostra que há outras pessoas 
inteligentes na sala que concordam com você (e que podem ter mais capital 
de relacionamentos que você). Trata-se de expor as melhores práticas que 
os experts concordam que sejam a decisão correta. Se nove de dez designers 
concordam, por que seu líder não faria o mesmo? Nem sempre a maioria 
vence, mas, sem dúvida, é uma situação mais atraente do que ter um único 
indivíduo defendendo o seu argumento sozinho junto a um gerente que não 
demonstra muita simpatia. 


Peça ajuda 

Em reuniões de design, queremos ter certeza de que há outras pessoas que 
estão preparadas para fazer boas perguntas, dar ênfase a elementos 
importantes específicos ou defender os designs que propomos. Talvez não 
nos lembremos de tudo que deva ser comunicado; desse modo, ter alguém 
que possa se manifestar na conversa para incluir qualquer informação que 
tenhamos esquecido é extremamente importante. Elas podem fazer uma 
pergunta que force você a dar uma resposta bem articulada, ou podem 
simplesmente reforçar o que você já disse. 


Em geral, em equipes bastante integradas, isso acontece naturalmente. Se os 
outros membros de sua equipe tiverem familiaridade com o trabalho, é 
comum que eles se manifestem na reunião quando perceberem que você se 
esqueceu de mencionar algo importante. Ao notar isso, seu colega de 
trabalho poderia dizer: “Mostre o que acontece quando você clica o botão”. 
Ou, se houver mais de um design sendo apresentado, eles se pronunciarão 
dizendo que “a primeira opção é melhor porque...”, reforçando o que você 
Já disse e mostrando que você conta com o apoio de outras pessoas na sala. 


Recomendo que você seja direto com as pessoas sobre a necessidade de 
contar com a ajuda delas. Não há problema em pedir, com antecedência, 
que as pessoas deem seu apoio. O propósito é defender a sua proposta e 
mostrar que há outras pessoas que concordam com você. Seja aberto com as 


pessoas quanto à necessidade de contar com o apoio delas, solicite ajuda e 
peça a elas que se manifestem se a situação assim o exigir. 


Identificando as pessoas 


O processo de conseguir a adesão das pessoas para a solução que você 
planeja ocorre muito mais em reuniões de um para um do que em uma sala 
de reuniões. As pessoas podem ficar relutantes em concordar em um 
ambiente de grupo, se souberem que o executivo no comando tem uma 
ideia diferente. Sua função é trabalhar de antemão com as pessoas e 
descobrir quem concorda com seus designs, até mesmo antes que essa 
conversa ocorra. Você deve identificar os votos indecisos que farão você ter 
a maioria, ou pedir às pessoas que estejam preparadas para ajudar você. 
Certifique-se de conhecer outras pessoas e ter relacionamentos suficientes 
para que essas pessoas confiáveis estejam à disposição. Isso não é algo que 
você possa deixar para ser resolvido imediatamente antes da reunião. 


O lugar mais fácil para conseguir esse apoio é na sua equipe: outros 
designers ou desenvolvedores que já fazem parte da discussão e do processo 
de design. Você já contará com a adesão dessas pessoas, e elas participaram 
da discussão que resultou na decisão que você apresentará. Elas devem 
estar sempre preparadas para vir em sua defesa caso a situação tome uma 
direção inesperada. Contudo, não é suficiente apenas supor que elas estarão. 
Se houver um conceito, uma ideia ou um design que você ache que vá 
encontrar resistência, seja direto com essas pessoas e deixe que elas saibam 
que talvez você precise de ajuda. 


No entanto, sua equipe não precisa ser a única fonte de apoio. Também será 
conveniente procurar outras pessoas na empresa que tenham interesse em 
seu projeto e possam ter alguma influência da qual você possa se beneficiar. 
Quase sempre, há outras pessoas que entendem o que você está fazendo, se 
sentem empolgadas com o projeto e não podem esperar para vê-lo ser bem- 
sucedido. Pode ser alguém com quem você costumava trabalhar em uma 
área diferente, ou uma pessoa que parou em sua mesa, viu os designs e 
pareceu ficar empolgada. 


Identifique essas pessoas e as envolva na discussão. Convide-as para a 
reunião, se for apropriado, e deixe que elas estejam preparadas para se 
manifestar caso seja necessário. Explique a elas do que se trata a reunião, 


dê-lhes uma cópia da agenda e dos designs com antecedência e peça a ajuda 
delas diretamente. Não há problemas, inclusive, em dizer que você quer que 
elas se pronunciem caso haja alguma divergência. Se for possível, aponte as 
áreas específicas com problemas, as quais você acha que serão um ponto de 
discussão, e converse sobre o modo como elas podem ajudar. Dê-lhes 
qualquer dado ou explique outros raciocínios que você possa ter feito. Você 
quer que essa pessoa seja seu representante, esteja confiante na capacidade 
que ela tem de dar apoio a você e concorde que suas soluções são as 
melhores. 


As pessoas entendem 


Eu estava em uma reunião com o presidente de um grande site de comércio 
eletrônico e estávamos apresentando alguns designs implementados 
recentemente, assim como alguns conceitos novos que estavam presentes 
no trabalho. A reunião correu bem. Houve algumas perguntas feitas por ele, 
as quais fui capaz de responder, e saímos da reunião com uma energia boa e 
uma lista de itens a serem considerados para outra rodada de revisões. Logo 
depois, outra executiva me chamou de lado e disse o seguinte: “Ei, me 
desculpe por não ter estado muito disponível, mas eu realmente quero que 
seu projeto tenha sucesso e gostaria de ajudar se puder. Talvez, da próxima 
vez, possamos rever tudo antes dessas reuniões para que eu possa apoiar 
você e possamos todos falar com uma só voz”. 


Eis uma pessoa que entendia a importância da comunicação com os 
stakeholders. Embora ela mesma fosse uma das stakeholders, percebeu que 
havia uma oportunidade para que trabalhássemos juntos a fim de alcançar o 
melhor resultado. Ela gostava de nossas ideias, confiava em nossa expertise 
e queria garantir que não tivéssemos obstáculos. Nem é preciso dizer que 
ela passou a fazer parte da minha rede de apoio. Ainda que não estivesse 
envolvida em todas as reuniões do projeto, criei o hábito de manter contato 
com ela regularmente, mantendo-a informada sobre nossos designs e 
permitindo que ela fosse nossa defensora nas discussões que ocorriam fora 
de nossas apresentações formais. 


Lembre-se sempre de que outras pessoas podem ajudar você a realizar 
aquilo que você deseja. Aprenda a construir esses relacionamentos e 
permita que agreguem valor à discussão. Identifique as pessoas que podem 


ajudar você a alcançar o seu objetivo e crie condições para que elas tenham 
sucesso junto com você. Ter esse pequeno grupo de pessoas que apoie você 
em uma reunião cria uma atmosfera de consenso. Mostra que você sabe do 
que está falando porque há outras pessoas que concordam com você. Além 
disso, a responsabilidade pela decisão é distribuída por toda a equipe. Essa 
não é a ideia de uma única pessoa, mas uma ideia que conta com o apoio de 
outras pessoas também. Mais do que isso, dá uma oportunidade para que 
outras pessoas falem a seu favor. Talvez você descubra que não terá de falar 
tanto para se expressar porque outras pessoas farão isso por você. Para um 
executivo que discorde de sua solução, será muito mais difícil insistir que 
você a mude se os outros especialistas na sala concordam com você. 


Faça um ensaio 


Agora que você entende seus stakeholders, eliminou as distrações, 
antecipou suas reações e reuniu um grupo de pessoas que darão apoio a 
você, é hora de analisar a reunião passo a passo, treinar a sua apresentação e 
deixar todos os envolvidos preparados. O nível de importância da reunião, 
em geral, determina o quanto você precisa treinar, mas acho que você ainda 
deve fazer disso um hábito, mesmo para reuniões menos importantes. Seja 
uma standup diária ou uma grande apresentação para um executivo, cada 
uma das ações a seguir ajuda a criar uma estrutura para orientar a conversa. 
Recomendo colocar todas em prática em todas as ocasiões, mas o tempo 
que você investirá será diferente para cada situação. 


E se as discussões forem por email ou bate-papo? 


É comum que as discussões de design ocorram por meio de métodos assíncronos 
de comunicação. Afinal de contas, as pessoas trocam mensagens, abrem ordens de 
serviço e enviam emails. É muito mais conveniente do que agendar uma reunião, 
particularmente em empresas que trabalham remotamente. Eu tenho duas 
abordagens para discussões de design assíncronas. 


Abordagem 1: Não faça isso 


Falando sério, simplesmente não faça suas reuniões de design dessa forma. Evite-a 
o máximo possível. Ela rebaixa o seu trabalho ao colocar um foco indevido na 
parte visual, ao mesmo tempo que permite que qualquer um possa ter uma reação 
automática, sem que você possa ajudá-los a compreender o seu raciocínio. Tomar 
decisões dessa forma com a sua própria equipe pode ser conveniente se todos 


tiverem o mesmo entendimento e empregarem o mesmo vocabulário; porém, 
muitas informações se perdem quando a reunião envolve stakeholders que não são 
designers. Em minha opinião, não vale a pena correr esse risco. 


Abordagem 2: Use um vídeo 


Para contornar as desvantagens de uma comunicação assíncrona, ao mesmo tempo 
que você valoriza o tempo e a atenção de todos, recomendo gravar a sua 
apresentação de design e compartilhar esse vídeo, em vez de usar capturas de tela 
estáticas e mensagens diretas. Isso implica utilizar um software de gravação de tela 
e descrever seus designs como se vocês estivessem juntos na sala. 


Há duas vantagens importantes ao usar um vídeo dessa forma. Em primeiro lugar, 
o vídeo permite que as pessoas ouçam e vejam você. A linguagem corporal, a 
apresentação e o tom são preservados quando um vídeo é usado. Nada disso estará 
presente se você fizer o mesmo utilizando um programa de bate-papo. Em segundo 
lugar, isso forçará as pessoas a esperarem até que possam assistir ao vídeo e 
responder de forma apropriada. É menos provável que elas assistam ao vídeo 
enquanto estiverem em outra reunião ou na fila do aeroporto. Elas esperarão até 
terem a capacidade mental e o espaço tanto para assistir como para responder, 
reduzindo as chances de terem uma reação automática. 


Descobri que gravar vídeos como esses é muito eficaz. Além disso, meus 
stakeholders adoram e compartilham esses vídeos, e me pedem para continuar 
fazendo isso. E uma relação em que todos saem ganhando. 


Eis algumas dicas para que seus vídeos sejam eficazes: 


* Escreva um pequeno roteiro para que você saiba o que vai dizer, mas não dê a 
impressão de que está lendo. 


* Seja breve. Tenho constatado que dois minutos e meio é a duração perfeita. Até 
cinco minutos podem ser necessários, mas procure manter o vídeo o mais breve 
possível. 


* Inclua um picture-in-picture de sua webcam para que as pessoas possam ver o 
seu rosto. Nem todo software permite usar esse recurso, mas, se for possível, 
isso dará um toque humano que será benéfico. 


* Compartilhe o vídeo com um link; não o envie como um anexo. Você não vai 
querer lotar a caixa de entrada de alguém. Às vezes, os anexos no email ou no 
software de bate-papo ficam travados. Usar serviços de hospedagem ou de 
streaming de vídeos (YouTube, Vimeo) é a melhor solução. 


Para onde vamos 


Macacos Gatinhos 


e 


Não tive permissão para compartilhar nenhum de meus vídeos de projetos reais, mas dá para você ter 
uma ideia. 


Faça uma lista 


A maioria das pessoas compreende a importância de ter uma agenda para 
uma reunião, e ela tampouco deve ser subestimada em uma reunião de 
design com os stakeholders. Para uma apresentação aos executivos, você 
provavelmente já deve ter um esquema bem planejado em um conjunto de 
slides para o conteúdo que será abordado. Isso é bom, e você terá mais 
chances de manter o controle dessa forma. Entretanto, eu ainda recomendo 
que você tenha uma versão impressa separada de sua agenda para consulta. 
As discussões sobre design naturalmente resvalam para outros assuntos e 
talvez seja difícil manter as pessoas concentradas na tarefa. Sei que 
imprimir agendas em papel é um desperdício, mas tenho notado que ter uma 
cópia em papel é muito mais eficaz do que ter um slide que desapareça 
depois que você avança para o próximo item. Além disso, você se sentirá 
mais confiante se não tiver de ficar lidando com tecnologia (mesmo que seja 
um tablet ou um telefone à parte) para saber em que ponto está. 


Até mesmo para reuniões rápidas com a sua própria equipe, por exemplo, 
um standup diário, ainda recomendo organizar uma agenda rápida ou uma 
lista de itens. É muito fácil se esquecer do que você pretendia falar ou se 
distrair com detalhes sobre outro assunto. Se você for como eu, deve passar 


o dia trabalhando em vários designs (talvez até mesmo em vários projetos) 
ao mesmo tempo. Um colega de trabalho interromperá você para perguntar 
sobre uma interação, o que fará você reavaliá-la de imediato. No meio da 
noite, você acorda e percebe que há um caso de uso muito importante que 
ninguém havia considerado. Você precisa de um lugar para anotar esse tipo 
de informação para que não se esqueça de analisá-la com as pessoas 
relevantes. Pessoalmente, gosto de usar um aplicativo simples para 
anotações que se sincronize com todos os meus dispositivos; assim, mesmo 
que tenha saído para fazer compras, posso adicionar um item em minha 
agenda em constante evolução para a próxima reunião e, em seguida, livro 
minha mente da responsabilidade de ter de me lembrar do assunto. 


Não é necessário criar um esquema sofisticado, uma lista simples bastará. 
Mesmo que sua reunião seja com uma só pessoa, uma lista como essa 
servirá de guia para ajudar você a saber se a reunião foi bem-sucedida. Até 
mesmo um mínimo de preparação ajudará. Sempre faça uma lista! 


Treine em voz alta 


Também é importante que você treine para a reunião com antecedência, 
falando em voz alta. É isso mesmo: como em um ensaio de uma peça de 
teatro na escola, você deve entrar em uma sala, falar sobre todos os itens 
que estiverem em sua agenda como se já houvesse pessoas presentes, e até 
mesmo antecipar e responder a perguntas simuladas em voz alta. Você já 
antecipou de que modo as pessoas responderão; portanto, faça uma 
simulação da reunião em sua mente e responda verbalmente às perguntas 
que elas fizerem, em uma sala vazia. Treinar o que você vai dizer dá a você 
a oportunidade de ouvir suas palavras. Ouvir você mesmo falando em voz 
alta é muito diferente de como a fala soa em sua mente. Além do mais, você 
se verá dizendo frases que poderiam ser formuladas com outras palavras, 
frases que não ajudam em nada ou são repetitivas. 


A ideia de uma reunião simulada pode parecer tola, mas é realmente muito 
importante. Quanto mais você treinar abordando todo o conteúdo, menos a 
sua mente terá de pensar na agenda, e mais capacidade mental você terá 
para manter o foco na hora da reunião. Você registrará tudo na memória. 
Queremos reduzir nossa própria carga cognitiva, até o ponto em que 
conduzir a reunião seja muito fácil. Além disso, as decisões de design 


podem ser particularmente difíceis de entender, e talvez haja motivos 
subjacentes para as suas decisões, as quais você ainda não havia descoberto. 
Percebi que sou capaz de identificar algumas das minhas próprias 
motivações para o design simplesmente falando para mim mesmo em voz 
alta. 


Não tenho vergonha de admitir que já passei inúmeras horas de minha 
carreira treinando dessa forma: andando de um lado para outro em meu 
escritório, apresentando o conteúdo para um quadro na parede e até mesmo 
respondendo a perguntas de membros de meu público-alvo imaginário. Já 
fiz o mesmo em meu carro, enquanto corria ou em um canto do aeroporto, 
enquanto esperava meu voo. Uma pessoa que estivesse passando poderia 
achar que sou louco, falando e gesticulando como se houvesse outra pessoa 
comigo. Contudo, o hábito de treinar para uma reunião é uma das únicas 
maneiras de saber como a sua fala soará. 


Como no caso das agendas, o quanto você precisa praticar variará de acordo 
com a importância da reunião. Uma grande apresentação para o CEO exige 
muito treino. Uma reunião diária com seu chefe exigirá menos, mas 
continua sendo uma boa ideia, caso você não se sinta muito seguro sobre 
como deve falar. Para uma reunião importante, eu poderia reservar a sala de 
reuniões no dia anterior para poder treinar no mesmo ambiente na medida 
que for necessário. Para um telefonema simples, posso ficar em minha 
escrivaninha e falar dos itens da agenda uma ou duas vezes a fim de 
aumentar o meu nível de confiança. Você deve decidir o volume de prática 
necessário para garantir que tenha a capacidade mental para ser articulado 
na hora da reunião. 


De modo geral, ouvir a si mesmo dizendo algo em voz alta dá um novo 
sentido às suas palavras, faz com que elas fiquem gravadas na memória e é 
o ambiente perfeito para testes. Treinar para uma reunião é o teste de 
usabilidade para ser articulado: você consegue passar por todos os itens e 
garantir que tudo funcionará conforme esperado. Se não funcionar, ainda 
haverá tempo para fazer ajustes antes de a reunião começar. 
Independentemente da importância das reuniões, sempre treine para elas. 


Deixe todas as pessoas preparadas 


Por fim, antes de se dirigir à sala de reuniões, converse rapidamente com 


todas as pessoas envolvidas em sua rede de apoio. Algumas pessoas 
chamam isso de “pré-jogo” ou “concentração” 2 Não importa o nome que 
você dê, revise a agenda, verifique cada item e anote aqueles que são 
importantes. Peça para as pessoas se manifestarem em pontos específicos e 
certifique-se de que não haja nada faltando. Essa é uma ótima oportunidade 
para que um colega confira o seu trabalho e verifique se você está no 
caminho certo para obter o apoio para os seus designs. Não precisa demorar 
muito. Apenas cinco ou dez minutos antes da reunião serão suficientes, mas 
isso ajudará você e seus colegas a estarem preparados para fazer a 
apresentação e responder. 


Lembre-se de que o propósito principal de tomar tanto cuidado em se 
preparar para discutir as decisões de design é reduzir a carga cognitiva, 
tanto de seus stakeholders como a sua. Assim como consideraríamos a 
usabilidade em um design, devemos dar a mesma oportunidade às nossas 
reuniões, com o intuito de melhorar o que as pessoas veem, otimizar o fluxo 
da conversa e testar nossas suposições, antes que tudo comece. Se nossos 
stakeholders tiverem a capacidade mental para manter o foco nas decisões 
mais importantes, é mais provável que tenhamos conversas produtivas e 
úteis para a experiência dos usuários. Quando nós mesmos temos a 
capacidade mental disponível, sem que haja necessidade de nos lembrarmos 
da agenda, também poderemos manter o foco em sermos articulados e em 
responder com atenção aos feedbacks. 


Treinar para uma reunião é o teste de usabilidade para ser articulado. 


Se você constatar que sua reunião ocorre exatamente conforme esperado, é 
um bom sinal de que você fez sua lição de casa e está preparado para 
explicar suas decisões de design. Permita que isso aumente o seu nível de 
confiança na hora da reunião, pois a confiança também ajudará você a ser 
mais articulado e lhe dará a perspectiva necessária para realmente ouvir os 
feedbacks que estão prestes a serem dados. 


1 As empresas farmacêuticas tiram proveito disso em comerciais de TV inserindo as 
advertências sobre seus medicamentos exatamente no ponto em que as pessoas 
perdem a concentração. 


2 “Stensil” está sujeito à licença CCO 1.0. Domínio público. Para ver uma cópia dessa 
licença, acesse: https://creativecommons org/licenses/ccO/1.0. 


3 Essa era uma versão antiga do Axure, que não incluía uma opção para desativar a 
apresentação desse painel. Em versões mais recentes, é possível remover esse painel 
do protótipo. 

4 Isso também é conveniente para que você, como apresentador, não compartilhe 
acidentalmente quaisquer notificações de mensagens inapropriadas que chegarem 
enquanto você estiver compartilhando sua tela. 


5 Na verdade, eu odeio o uso exagerado de referências a esportes nos negócios. 
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Ouça para entender 


À reunião 
Fazer o 


Entender Ouvir Responder follow-up 


vo (E e————s 


Agora que você já se preparou para apresentar seus designs e antecipou 
quais serão as respostas, você terá a oportunidade de se encontrar 
pessoalmente com as pessoas que têm influência no projeto. É nesse 
momento que nossa habilidade de comunicação realmente se manifesta, 
mas não por causa de algo que vamos dizer. Nossa primeira tarefa deve ser 


ouvir. 


Ouvir é uma habilidade importante em qualquer relacionamento, e não é 
diferente quando discutimos as decisões de design. Ouvir não é apenas 
esperar que a outra pessoa pare de falar para que possamos começar a 
responder. O propósito de ouvir com atenção é garantir que compreendemos 
nossos stakeholders antes de responder. 


Uma resposta articulada exige o uso de aptidões implícitas, como ouvir sem 
interromper, escutar o que os stakeholders não estão dizendo, descobrir o 
verdadeiro problema que eles estão tentando resolver e, então, fazer uma 
pausa antes de prosseguir. Também devemos usar técnicas mais explícitas, 
como fazer anotações e perguntas, e repetir ou reformular o que foi dito. Ao 
utilizar essas técnicas, podemos demonstrar explicitamente que estamos 
sincronizados. Em última análise, queremos ter certeza de que entendemos 
exatamente o que eles estão dizendo para que possamos formular a melhor 
resposta possível. 


Ouvindo implicitamente 


Ouvir implicitamente é aplicar a habilidade de entender o que as pessoas 
estão dizendo sem fazer nada específico ou explícito para demonstrar que as 
ouvimos. Uma pessoa que ouve implicitamente é aquela que consegue 


organizar com rapidez o que foi dito e extrair um sentido, sem nenhuma 
outra pista externa ou informações adicionais. No caso de feedbacks sobre 
design, gostaria de destacar quatro maneiras de explorar implicitamente o 
feedback de um stakeholder a fim de chegar ao cerne da informação à qual 
devemos responder. 


Deixe que eles falem 


Sua primeira tarefa é deixar que seus stakeholders falem. Permita que 
digam o quanto precisarem e não os interrompa. As pessoas gostam de 
ouvir a si mesmas falarem, e elas precisam de tempo e espaço suficientes 
para se expressar sem sentir que estão sendo apressadas. 


Pode ser difícil encontrar um equilíbrio nesse caso, pois você também não 
quer que a reunião saia do controle, particularmente se as pessoas estiverem 
dizendo algo que você sabe que está incorreto ou carece de fundamento. 
Além disso, nós também gostamos de ouvir a nós mesmos! É difícil ouvir 
alguém falar de nosso trabalho de design sem nos sentirmos impelidos a nos 
manifestar. Afinal de contas, é sobre o nosso design que estão falando. 
Contudo, não as interrompa. Deixar que elas terminem será vantajoso para 
você. 


Por quê? Algumas pessoas querem apenas parecer inteligentes. Pode ser 
que haja outras pessoas na sala a quem elas estão tentando impressionar. 
Conforme mencionei no Capítulo 2, você nunca sabe quais são os tipos de 
política que estão em jogo. Outras pessoas aprendem de forma audível, e o 
processo de falar sobre algo as ajuda a entender com mais clareza. Com 
efeito, pelo fato de poder ser muito difícil falar de design, o processo de 
falar sobre o raciocínio de outra pessoa talvez permita que os stakeholders 
compreendam a ideia com o tempo. Eles poderiam até mesmo explicar seu 
design para eles mesmos nesse processo, sem que você precise dizer uma só 
palavra. Qualquer que seja o motivo, permita que seus stakeholders digam o 
que precisam dizer antes de prosseguir com a discussão. 


Há três vantagens em deixar que os stakeholders falem o quanto quiserem: 


Eles se expressarão com mais clareza 


A medida que falam, as pessoas naturalmente fazem repetições e 
reformulam o que querem dizer, em um esforço para se comunicar com 
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mais clareza. Como seu trabalho é entender exatamente como os 
stakeholders veem seus designs, é essencial que você dê a eles o espaço 
necessário para que eles descrevam esses designs. Nem todos conhecem o 
vocabulário a ser usado para discutir um design, e algumas tentativas 
talvez sejam necessárias para que eles possam se expressar de forma 
completa. 


Faz com que se sintam confiantes de que foram compreendidos 

Quanto mais as pessoas puderem falar aquilo que precisam para conseguir 
comunicar algo, mais confiantes elas estarão de que foram bem-sucedidas. 
Você quer que seus stakeholders saibam que eles se comunicaram com 
eficiência, de modo que não possam dizer que houve algum mal- 
entendido em virtude da falta de aptidão deles em se comunicar (ou de sua 
falta de aptidão para ouvir). Deixar que os stakeholders falem dá espaço 
para que eles tenham esse nível de confiança. 


Mostra que você valoriza o que eles estão dizendo 
Não importa o que você diga em resposta, permitir que os stakeholders 
falem o quanto quiserem mostra que você aprecia o que eles estão dizendo 
e que você está escutando cada uma de suas palavras. Quando você faz 
com que eles se sintam assim, o laço de confiança se fortalece e faz com 
que as chances de eles concordarem com você depois aumentem se 
souberem que foram ouvidos. 


Enquanto os stakeholders falam, mostre que você valoriza as informações 
que eles estão dando, mantendo contato visual e balançando a cabeça. Fique 
atento a palavras específicas usadas por eles; por exemplo, preste atenção 
em qualquer jargão que usarem e nos termos que eles preferem ao descrever 
seus designs. A maioria das pessoas não usará uma linguagem como 
controle de UI, elemento de entrada, lista suspensa, pop-over ou dica de 
contexto (tooltip). Parte de seu trabalho ao ouvir é identificar as palavras 
com as quais eles se sentem à vontade para descrever seus designs, de modo 
que você também possa utilizar esses termos ao responder. Será difícil 
conseguir o apoio deles se você utilizar um vocabulário diferente; portanto, 
adote as palavras que eles utilizam e (em algum momento) encontre 
maneiras de ensinar a eles os termos que serão mais eficazes no futuro. 
Veremos esse assunto com mais detalhes na seção “Repita e reformule”. 


De modo geral, permitir que os stakeholders falem livremente cria uma 
atmosfera na qual eles sabem que podem se expressar sem serem 
interrompidos; isso aumenta as chances de eles apresentarem os pontos de 
vista importantes de que você precisa para ser eficaz. Eles sabem que 
poderão se expressar e serão ouvidos. 


Ouça o que não está sendo dito 


Nem tudo que nossos stakeholders disserem ficará claro de imediato. Às 
vezes, temos de ir além das palavras propriamente ditas para extrair o 
significado que eles pretendiam expressar. Assim, outra parte importante ao 
ouvir é ouvir o que não está sendo dito. Você deve tentar entender tanto o que 
eles expressarem em voz alta como aquilo que jamais saiu de seus lábios. 
Qual é o subtexto? Qual é o elefante na sala que ninguém quer realmente 
mencionar? Muitas vezes, o que as pessoas dizem e o que elas querem dizer 
podem ser coisas totalmente diferentes. 


Isso talvez seja mais importante no design do que em outras áreas, somente 
porque o design é mais subjetivo e as pessoas nem sempre sabem ao certo 
como se expressar. Além disso, seus stakeholders sabem que esse design é 
algo que você fez. Você o criou. É o seu filho. Eles podem ser sensíveis a 
esse fato e tentar falar com você a respeito de um problema que viram de 
formas indiretas. Se for esse o caso, em geral, as pessoas responderão com 
perguntas, em vez de discordarem diretamente. “Ah, isso é interessante. Por 
que você usou a chamada para a ação principal nesse ponto em vez de 
utilizar a segunda?” O subtexto poderia ser o fato de essa pessoa achar que 
a chamada para ação secundária seria uma melhor opção, mas ela 
simplesmente não quer ser explícita e dizer isso dessa forma. Quando 
alguém emprega a palavra “interessante” em uma resposta aos seus designs, 
é um sinal de que elas talvez discordem de sua abordagem. 


Conforme já mencionei antes, há outros fatores envolvidos em qualquer 
reunião, dos quais simplesmente não temos conhecimento. Se alguém 
estiver implicando com algo irrelevante, essa pessoa talvez esteja tentando 
dizer algo a outra pessoa que está na sala. Ou, se seu gerente não se 
importava com os gráficos do painel de controle na semana passada, mas, 
de repente, passou a insistir agora que sejam modificados, talvez ele esteja 
reagindo à reunião da qual acabou de sair. Em geral, podemos esperar que 


haja outros acontecimentos em curso. 


Gentil Paula 


Em um de meus cargos anteriores, lancei uma ideia sobre uma interface 
web que era um pouco incomum. Minha gerente respondeu com entusiasmo 
porque ela sabia que eu estava empolgado com a ideia e queria me manter 
motivado. Ela era um tipo de pessoa sempre solidária. Minha gerente 
concordou em me deixar passar as sextas-feiras trabalhando nesse projeto 
secundário, de modo que não atrapalhasse meu trabalho habitual durante a 
semana. Durante vários meses, trabalhei nessa nova ideia e, quando ela 
ficou pronta, levei-a para que ela visse. Ela foi muito gentil, mas, em vez de 
dizer de imediato que era um desastre, ela fez perguntas sobre o meu design 
de uma maneira que mostrasse suas falhas. Como era meu projeto de 
estimação, naturalmente fiquei um pouco na defensiva. Respondi às 
perguntas dela da melhor maneira que podia, mas, no fim, não ficou claro 
para mim o que ela queria que eu fizesse. Olhando para trás, hoje percebo 
que ela não achava que era uma ideia na qual valesse a pena investir. Eu 
teria preferido que ela tivesse sido direta comigo sobre a questão, mas eu 
não podia controlar o modo como ela decidiu responder ao meu trabalho. 
Devemos tentar ouvir o que os stakeholders não estão dizendo se quisermos 
saber qual é a melhor maneira de responder. 


Dan, o desanimador 


Em outra empresa, trabalhei em um site de marketing para um serviço 
online. O site estava totalmente inutilizável: links ruins, imagens faltando e 
cópias de texto desatualizadas. Parecia uma casa abandonada. O fato é que 
havia um número incomum de perguntas ao serviço de assistência, 
relacionadas a problemas simples nesse site. Eu sabia que o dono do 
produto não tinha os recursos necessários para refazer o design do site. Para 
mim, era um trabalho fácil: um site simples de cinco páginas, cujo template 
e a atualização poderiam ser feitos rapidamente. Decidi refazer o design 
enquanto estava no intervalo entre outros projetos. Eu achava que um site 
funcional, com um aspecto melhorado, seria melhor do que um site perfeito, 
mas que demorasse infinitamente mais para ser implementado. O primeiro 
design que mostrei para o dono do produto foi recebido sem entusiasmo. 


“Ah... hum, uau, Tom. É realmente bom, muito obrigado. Parece muito 
melhor, mas você realmente não precisava perder seu tempo com isso” — foi 
a reação dele. Eu supus que ele estivesse apenas sendo gentil. Ele não era 
meu chefe e não tinha autoridade para me pedir ajuda, mas o site 
claramente precisava de um pouco de carinho e cuidados. Que mal poderia 
haver? Concluí os designs, criei as páginas e as coloquei em um servidor de 
staging. Novamente, o dono do produto não ficou animado. Ele apreciou 
meus esforços e deu o sinal verde para colocar o trabalho no ambiente de 
produção, mas não parecia se importar nem um pouco com o fato de eu ter 
feito esse favor a ele. 


Algumas semanas depois de ter colocado o trabalho no ambiente de 
produção, nosso grupo recebeu um email anunciando que esse serviço seria 
imediatamente desativado, o site de marketing seria colocado offline, e os 
clientes existentes teriam um período de transição para encontrar um novo 
serviço. Só posso supor que esse dono de produto não poderia ter me dito 
que o serviço estava sendo descontinuado na época. Ele tentou desencorajar 
meu trabalho no site, mas eu não fui astuto o suficiente para ler nas 
entrelinhas. Embora não me arrependa do tempo que investi nesse trabalho 
(porque tenho orgulho do resultado), eu poderia ter redirecionado meus 
esforços para outra atividade que tivesse mais impacto se eu fosse 
suficientemente habilidoso para ouvir o que não estava sendo dito. Eu 
deveria ter me esforçado mais para compreender a falta de entusiasmo desse 
gerente de produto antes de avançar cegamente, por conta própria. É fácil 
deixar de perceber essas pistas sutis, e elas exigem que tenhamos uma 
compreensão aguçada de nossos stakeholders. 


Descubra o verdadeiro problema 


Enquanto estiver ouvindo o feedback de seus stakeholders, trabalhe para 
descobrir o verdadeiro problema que eles estão tentando resolver. Em geral, 
nossos stakeholders veem uma necessidade que não está sendo atendida 
pelos nossos designs e podem expressar isso com uma sugestão que não é a 
solução adequada. Portanto, não se concentre naquilo que eles acham que 
precisa ser mudado ou nas palavras específicas que eles usarem; em vez 
disso, mantenha o foco no problema subjacente que eles estão tentando 
resolver ao sugerir essa mudança. 


As pessoas pensam naturalmente em soluções, em vez de identificarem 
antes o problema. É muito mais fácil dizer: “Mova esse botão para lá”, em 
vez de reconhecer que o problema é a proximidade entre o botão e o 
selecionador de data. Outras vezes, as pessoas utilizam uma linguagem 
vaga simplesmente porque não sabem como expressar sua reação a um 
design. Quando alguém diz: “Tem cores demais aqui! Parece um arco-íris”, 
o que elas realmente querem expressar é: “O número de cores causa 
distrações e eu não sei para onde devo olhar, ou não sei o que é importante”. 
Podemos ajudar nossos stakeholders a entenderem o verdadeiro problema 
fazendo perguntas e repetindo-as para eles. Não há nenhum problema em 
fazer perguntas diretas: “Qual é o problema que você está tentando resolver 
ao fazer essa sugestão”. 


Entradas reordenadas 


Certa vez, uma cliente me pediu para mudar a ordem de alguns campos de 
entrada de texto em um formulário. Era uma solicitação simples, mas se 
opunha àquilo com o qual havíamos concordado antes. Quando perguntei o 
motivo, ela não expressou nada além de uma preferência em sua resposta: 
ela apenas preferia que os dados fossem inseridos daquela forma. Pedi a ela 
que me desse um exemplo de outra aplicação que fizesse aquilo, e ela me 
enviou a planilha que havia recebido, a qual havia sido exportada pelo 
sistema que ela usava para gerar relatórios para suas reuniões. Em sua 
explicação, ela mencionou que a ordem das colunas na planilha precisava 
estar de acordo com os dados inseridos no sistema. Ela achava que o modo 
como o usuário inseria os dados no formulário se refletiria no arquivo 
exportado. Ela não fazia ideia de que era possível personalizar a ordem dos 
dados no relatório para ela, de modo independente da entrada do usuário. Se 
eu tivesse feito aquela mudança simples, originalmente solicitada por ela, 
sem questionar, o resultado teria sido uma experiência não tão boa para o 
usuário. Ao tentar entender melhor o verdadeiro problema que ela estava 
tentando resolver, fui capaz de responder às suas preocupações e resolvê- 
las, sem nenhuma modificação no design. 
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Minha cliente pediu que eu mudasse a ordem de alguns campos de entrada porque ela não havia 
percebido que o arquivo exportado poderia ser ordenado de forma independente da entrada do 
usuário. 


Dados duplicados 


Outro projeto no qual trabalhei tinha uma sequência complicada de 
formulários que eram apresentados ao usuário na forma de vários passos. 
Inicialmente, o usuário inseria algumas informações sobre as pessoas no 
relatório, como nome, endereço, altura e peso; em seguida, ele escolhia o 
próximo formulário. Como queríamos que o usuário mantivesse o foco na 
tarefa sem se distrair, decidimos conduzi-lo a uma nova página sem a 
navegação, na qual os detalhes que ele havia inserido antes estariam 
totalmente visíveis na parte superior da view. 


Quando nossa cliente viu isso, ela disse que o usuário deveria ser capaz de 
editar os detalhes do paciente nesse segundo formulário, assim como no 
primeiro. Questionei isso porque o usuário havia acabado de inserir essas 
informações. Por que ele teria de alterá-las logo a seguir? Sua resposta foi 
confusa: ela se desviou do assunto, falou de um formulário do governo em 
papel que ela estava acostumada a preencher, alegou que não queria ter de 
treinar os funcionários, os detalhes deveriam ser inseridos corretamente da 


primeira vez e, às vezes, você poderia querer ter dois endereços diferentes 
para a mesma pessoa. Formulários em papel? Treinamento? Dados 
duplicados? Nada disso fazia nenhum sentido; portanto, comecei a fazer 
perguntas a ela. 


Case: IDX726354 avraois -2:14m Case: IDX726354 Pes Sê 
Sharmy Gosaman (Poent) Sherny Gossman (Patient) Height: 5' 8” 
PRE E 3105 Winchester Ct Bits Date: 03/22/1064 
Aurora, NL 60504 isa Femalo 
Add an Event 
ES pa O Neebdema Bent] 


Symptoms 


Concomitants 


Esta é uma versão simplificada, mas, em meu design original, o usuário se movia de um passo para 
outro horizontalmente; minha cliente expressou sua frustração por não ser capaz de editar as 
informações do Passo 1. 

Por fim, comecei a perceber que ela via esse aplicativo como uma versão 
digital do formulário em papel que ela havia mencionado antes. Na verdade, 
eu havia feito o design de modo que fosse parecido, mas as diferenças a 
distraíam. Depois de algumas decisões difíceis, decidimos que o segundo 
formulário não seria carregado em uma nova página, mas seria 
simplesmente carregado de forma inline, diretamente na página, abaixo do 
local em que o usuário houvesse inserido esses detalhes. Passamos de uma 
progressão horizontal para uma progressão vertical. Continuava sendo, 
efetivamente, a mesma interação, mas não precisar voltar para um passo 
anterior para ver as informações deu à usuária um maior senso de controle. 


Case: IDX726354 
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Sherry Gossman (Patient) 
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Patient Report: 


Symptoms: 


Concomitants: 


No design final, o usuário se movia verticalmente, o que deu à minha cliente um melhor senso de 
controle na inserção dos dados. 

Quando viu a nossa solução, a cliente concordou que era melhor, e nós 
passamos para o próximo design. No entanto, se tivéssemos feito as 
mudanças sugeridas por ela inicialmente, teríamos uma série de outros 
problemas de usabilidade. Ouvi-la e me esforçar para descobrir o 
verdadeiro problema que ela estava tentando solucionar ajudou a garantir 
que preservássemos a melhor experiência possível aos usuários. 


Em suma, a natureza visual do design leva naturalmente a mudanças nesses 
visuais para conseguir o resultado desejado. As pessoas fazem sugestões 
sobre como mudar o design, em vez de descreverem o problema que veem. 
Para a maioria das pessoas, é difícil pensar de forma concreta nos 
problemas de design e expressá-los. Elas apenas sabem que há algo que não 
parece certo. Consequentemente, precisamos ouvir suas soluções e conectar 
os pontos a fim de descobrir qual é o verdadeiro problema. 


A arte da pausa 


Uma última técnica para ouvir implicitamente é dominar a arte da pausa. 
Quando achar que os stakeholders acabaram de falar, simplesmente espere. 
Não dê sua resposta imediatamente. Em vez disso, faça uma pausa de vários 
segundos (talvez dois ou três) e permita que haja um silêncio, por mais 
desconfortável que possa parecer. Isso pode realmente ser um pouco 
embaraçoso, sobretudo em uma audioconferência ou um bate-papo com 
vídeo, em que há atrasos frequentes e pode ser difícil dizer se sua conexão 
caiu. Para evitar ambiguidades, você pode fazer um pouco de ruído dizendo 
algo que não seja comprometedor, por exemplo, “ok” ou “mm...”. Até 
mesmo mover algo em sua escrivaninha mostrará que você continua 
presente. Porém, independentemente de estar em uma chamada ou 
pessoalmente, vale a pena correr o risco de haver um desconforto a fim de 
garantir que seu stakeholder terminou de falar e haja uma pequena pausa na 
discussão. Se o silêncio for desconfortável demais, você pode criar uma 
lacuna dizendo: “Deixe-me pensar nisso por um instante”. Qualquer pessoa 
apreciará o fato de você querer um tempo para considerar o que ela disse. 


O propósito da pausa se desdobra em três: 


* Em primeiro lugar, você quer garantir que os stakeholders realmente 
acabaram de falar e não foi somente uma pausa que fizeram. As vezes, 
as pessoas param e, então, pensam imediatamente em outro detalhe ou 
em uma melhor forma de dizer algo. Se houver uma melhor forma de os 
stakeholders darem o feedback, você vai querer ouvi-los; as pessoas 
nem sempre se expressam da forma correta da primeira vez. Dê uma 
chance para que eles mesmos sejam articulados. Eles precisam se sentir 
bem acerca do que disseram, de modo que não possam dizer que houve 
um mal-entendido causado por uma escolha ruim de palavras. 


* Em segundo lugar, isso dá a você uma oportunidade para as ideias se 
assentarem, permitindo que as palavras dos stakeholders ressoem nos 
ouvidos de todos por um instante. Você permite que a conversa seja 
atenuada por um momento, o que dará a você uma chance para 
considerar rapidamente o modo como vai responder. Você não assume 
diretamente uma postura defensiva; em vez disso, aproveita o tempo 
para considerar o que foi dito e formular uma resposta apropriada. 
Bastará esses poucos segundos de espera para permitir que sua mente se 
ajuste e você esteja muito mais preparado para responder. 


* À terceira vantagem de fazer uma pausa é que você comunicará à outra 
pessoa que o que ela disse é suficientemente importante para você 
realmente considerar e pensar a respeito. Como você não foi direto para 
a conclusão, isso dará a impressão de que o que ela acabou de dizer é 
realmente importante. As pessoas querem ser ouvidas (ou, pelo menos, 
achar que foram ouvidas), e fazer uma pausa mostra que você levou a 
sério o feedback dado por elas. 


Todas essas técnicas de ouvir implicitamente devem ajudar você a ver e a 
ouvir o feedback de seus stakeholders. À medida que os ouvir, você fará um 
esforço consciente, não verbal, de realmente entender o que eles querem 
dizer. Essas atividades internas dão a você a oportunidade de organizar 
melhor o seu raciocínio, de modo que possa formular a resposta mais eficaz 
possível. 


Ouvindo explicitamente 


Além das atividades internas que empregamos para ouvir os feedbacks para 
o design, há também várias atividades explícitas que podemos usar para 
ouvir de modo mais apropriado. Ouvir explicitamente inclui demonstrar, de 
forma verbal, que você está escutando, bem como fazer algo que mostre 
distintamente que você está interessado na conversa. Em reuniões de 
design, fazer anotações, fazer perguntas e repetir ou reformular o que os 
stakeholders disseram são modos importantes de ouvir o feedback dado de 
modo eficaz. 


Anote tudo 


A primeira tarefa que você deve fazer ao ouvir é anotar. Você não vai se 
lembrar de tudo que seus stakeholders disserem ou sugerirem. Uma das 
melhores maneiras de ouvi-los é anotar o que eles disserem. Registre tudo, 
particularmente os itens cujo acompanhamento posterior seja necessário 
fazer. Mesmo em reuniões pequenas, é importante anotar as decisões que 
foram tomadas e registrá-las em algum lugar. Já recomendei registrar por 
escrito e fazer anotações em diferentes etapas do processo, e você sempre 
deve ter uma forma de tomar notas em suas reuniões. Talvez você jamais 
chegue a consultar suas anotações depois da reunião, mas isso não é um 
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problema. Fazer anotações é mais do que somente ter um lugar para 
registrar o que foi decidido. 


As anotações evitam que você tenha a mesma conversa novamente 
Fazer anotações é a única maneira de se lembrar do que foi discutido, e 
você terá um histórico que ajudará a evitar que a mesma conversa se 
repita no futuro. Percebi que a falta de anotações, muitas vezes, é 
responsável por falhas na comunicação, conversas repetitivas e mudanças 
de requisitos em vários projetos. Fazer anotações evita um retrabalho que 
impedirá você de ter sucesso ao explicar seus designs. 


Quando se trata de design, as anotações são essenciais porque as opiniões 
e as ideias sobre a decisão correta mudarão com o tempo. Se não fizer 
anotações, você não terá um histórico em papel para entender a lógica 
envolvida nas decisões originais. Você só terá o “ele disse, ela disse” e 
uma série de conversas que se repetem. Quando as decisões de design são 
tomadas verbalmente em uma reunião, é quase impossível se lembrar, 
mais tarde, dos motivos que levaram a essas decisões. Além do mais, 
alguns membros da equipe talvez não estejam presentes na reunião. Fazer 
anotações ajudará a deixá-los rapidamente sincronizados, sem a 
necessidade de narrar tudo o que aconteceu na reunião. 

Devo admitir que não sou das melhores pessoas para manter as anotações 
organizadas, mas eu as guardo, e já houve várias ocasiões em que 
decidimos tomar uma direção em uma interação específica, a qual foi 
questionada depois do lançamento para o público. “Ei, por que fizemos 
isso dessa forma?” Consegui encontrar minhas anotações de meses atrás e 
conversar com todos, e até mesmo lembrá-los de quem tinha sido a pessoa 
que havia sugerido a mudança, o motivo e a data. Se conseguir fazer isso, 
de modo geral, você fará todos ganharem tempo e permitirá que o 
trabalho avance. 


As anotações permitem que você possa manter o foco em ser articulado 


Pelos mesmos motivos discutidos no Capítulo 3, fazer anotações reduz a 
sua carga cognitiva e deixa sua mente livre para poder se concentrar em 
ser articulado em sua resposta. Quando você registra uma informação por 
escrito, não será mais necessário pensar nela. Se permitir que todas as 
ideias e feedbacks dos stakeholders fiquem vagando livremente em sua 


mente, você terá dificuldade para organizar essas sugestões de forma que 
o conduzam a uma resposta mais apropriada. Anote o que eles disserem 
para que você possa dar o próximo passo e formular suas respostas sem a 
necessidade de se lembrar de tudo de cabeça. 


As anotações fortalecem os laços de confiança com seus stakeholders 


Outra vantagem de fazer anotações é que o simples ato de escrever faz 
com que você pareça atento, inteligente e, como resultado, mais 
articulado. Tomar notas faz com que você pareça ser um bom 
comunicador. Faz com que a outra pessoa se sinta valorizada porque você 
se importa com o que ela diz a ponto de anotar. Ela se sentirá mais 
confiante de que você a ouviu e planeja considerar o que ela disse. 


Se tiverem essa impressão de você, as pessoas farão um trabalho muito 
melhor para ouvir e considerar a resposta que você lhes der 
posteriormente. Há um respeito mútuo, que funciona nas duas direções. 
Como resultado, muitas vezes, uso o ato de fazer anotações como uma 
forma de dizer às pessoas que eu as ouço e a discussão será feita da 
melhor maneira possível, mesmo que eu discorde do que elas estão 
sugerindo. Expressar algo verbalmente, como: “Ah, eu entendo o seu 
ponto de vista. Deixe-me anotar isso”, faz com que você ganhe a 
confiança da outra pessoa. 


As anotações mantêm a reunião sob controle 


Fazer anotações também é uma ótima maneira de garantir que o foco de 
sua reunião seja mantido, dando a você um lugar para registrar as partes 
da discussão que se desviem do tópico principal. As pessoas pensam 
praticamente sobre tudo em uma reunião de design, e é fácil perder o 
controle dela com algo que não seja o foco principal. 

Suponha que você esteja mostrando a página inicial para discutir a 
interação no menu de categoria, mas, quando seu chefe percebe que o 
formulário de login está confuso, repentinamente, a reunião toma uma 
direção diferente. Por estar fazendo anotações, você pode sugerir que a 
reunião sobre o formulário de login seja adiada se esse não for o propósito 
da reunião. “Sim, eu também notei como está o formulário de login hoje 
cedo. DeiXE-me fazer uma anotação a respeito e retomarei o assunto logo 
depois dessa reunião, mas, por enquanto, vamos manter o foco no menu 


de categoria.” Fazer anotações oferece a você um lugar natural para 
colocar as informações que poderiam causar distrações. 


Anotar por escrito passa a impressão de estarmos fazendo um registro 
mais permanente, em comparação com apenas dizer algo em voz alta. Dá 
a todos uma sensação de segurança de que o que foi dito é importante e 
não será descartado. 


Fazendo anotações mais apropriadas 


A melhor maneira de fazer anotações é pedir que outra pessoa faça isso por 
você. Isso deixa seu cérebro livre para manter o foco em ouvir e ser 
articulado. Se não houver ninguém que faça as anotações para você, 
encontre um colega que esteja disposto a ajudar. Ofereça-se para se 
alternarem na responsabilidade de fazer anotações nas reuniões um do 
outro. Poderia ser até mesmo alguém de um departamento ou projeto 
diferente, ou seja, qualquer pessoa disposta a fazer isso e que seja confiável 
para registrar a conversa. Você também pode gravar áudios ou vídeos da 
reunião, mas percebi que raramente tenho tempo para analisá-los depois e 
registrar as anotações perdidas. A melhor prática é documentar suas 
decisões para que você tenha um histórico prontamente acessível para 
consultar, mesmo que você faça isso por conta própria. 


Para aproveitar ao máximo as anotações feitas em uma reunião de design, 
elas devem ser: 


Acessíveis 


Armazene suas anotações em um local a que todos tenham acesso. 
Conforme veremos no Capítulo 9, fazer um acompanhamento posterior 
com suas anotações é uma parte importante do processo. Na reunião, 
basta se certificar de que todos possam vê-las ou tenham acesso a elas. 
Pode ser uma página wiki no repositório de seu projeto, uma página 
separada nos mockups de seu design, ou uma pasta ou documento 
compartilhado. Suas anotações devem estar sempre disponíveis a todos da 


equipe, mesmo durante a própria reunião. 


Organizadas 


Escreva suas anotações em cada item da agenda para que permaneçam 
associadas ao design em questão. Em geral, isso deve ser feito por página, 


por controle de UI ou por interação. Associe suas anotações a um item 
específico. Em geral, eu crio uma lista de itens contendo as anotações 
dentro de cada item da agenda, à medida que a reunião se desenrola. 


Específicas 
Anote os nomes das pessoas que fizeram a sugestão que você está 
registrando, assim como os nomes das pessoas que concordaram ou 
discordaram. Essa nem sempre é uma ciência exata, mas algo simples, 
como: “Cynthia sugere mudar a cor; Brian não tem certeza”, será útil mais 
tarde, quando você estiver tentando se lembrar de quem foi o responsável 
por sugerir a mudança. 


Definitivas 

Quando uma decisão é tomada, deixo isso claro, de forma explícita, para 
poder localizá-la mais tarde caso precise se lembrar dela, por exemplo: 
“Final: controle suspenso deve ser um menu pop-over”. Itens que ainda 
não tenham sido decididos também devem ser marcados para que você 
possa fazer o acompanhamento depois. Eu adiciono um ponto de 
interrogação para qualquer decisão pendente: “Reconsiderar o 
posicionamento das opções de ordenação (?)”. 


Passíveis de ação 

Praticamente todo item deve ter uma ação para acompanhamento 
posterior ou uma pessoa associada a ele. Anotar as ideias é conveniente, 
mas, se não houver nenhuma ação, praticamente não haverá sentido nelas. 
Por exemplo: “A ser feito: atualizar o protótipo com o novo controle”, ou, 
melhor ainda: “Chad vai atualizar o protótipo com o novo controle”. Se 
houver muitas tarefas de acompanhamento a serem feitas, talvez seja 
conveniente criar uma seção separada em suas anotações somente para 
documentá-las, para que não se percam em meio à lista de outras 
anotações. Em geral, eu crio um cabeçalho separado abaixo da agenda, 
que chamo de “Acompanhamento” (Follow up). 


Ter referências 


Adicione links, URLs, capturas de tela ou outros materiais para referência 
em suas anotações para que seja mais fácil explicar qual foi a razão da 
discussão. Se as pessoas sugerirem outros sites ou aplicativos como 
referência, adicione essas informações para ajudar você a se lembrar da 


conversa. Sem referências, será difícil se lembrar do que você quis dizer 
com “Veja como o SocialApp faz isso.” Acrescentar capturas de tela 
inline ou URLs junto da agenda faz com que suas anotações sejam muito 
mais valiosas no longo prazo. 


Voltadas para o futuro 

Além dos itens da agenda que devem ser discutidos de imediato, há 
sempre outras decisões de design que surgirão durante a discussão. Você 
precisa ter um local em suas anotações para adicionar itens que deverão 
ser discutidos na próxima reunião ou em um contexto diferente. Faço isso 
simplesmente acrescentando um novo cabeçalho chamado “Próxima 
reunião” (Next meeting) em minhas anotações. Ter essa área separada faz 
com que eu tenha um local onde posso organizar rapidamente os assuntos 
que estão fora da pauta e anotá-los para a próxima rodada de discussões. 


Inclua o porquê 


Nas discussões sobre design, é importante se lembrar de registrar não só 
quais decisões foram tomadas, mas também por que foram tomadas. Estamos 
tentando criar um registro de nossas decisões de design que nos ajudará a 
administrar nossas conversas futuras. Esse registro deve incluir o raciocínio 
que nos levou a tomar essas decisões, para nos ajudar a lembrar como 
chegamos a essa solução, antes de tudo. Se estiver consultando suas 
anotações no futuro e não houver nenhuma explicação sobre suas decisões, 
você não conseguirá evitar que essas conversas com seus stakeholders se 
repitam. No entanto, ao incluir uma explicação rápida do seu raciocínio, 
você terá um ponto de partida muito melhor para a discussão. Quando as 
pessoas questionam uma decisão que foi tomada em conjunto, raramente 
elas perguntam o que foi feito — essa parte é bem visível. Em vez disso, elas 
perguntam: “Por que fizemos isso dessa forma?”: se suas anotações não 
permitirem responder a essa pergunta, a discussão voltará para o ponto de 
partida novamente. 


Incluir o porquê pode ser tão simples quanto usar uma única expressão ou 
frase. Ela não deve ser longa nem detalhada, somente o suficiente para 
ajudar você a se lembrar dos motivos para ter feito o que fez: 


* Mudança da cor do botão para vermelho para acomodar os padrões mais 


recentes da marca. 
* À animação está sendo removida porque causa muitas distrações. 


* À cópia do texto deve ser posicionada acima dos campos do formulário, 
de acordo com os requisitos da equipe jurídica. 


* O menu suspenso passará a ser um campo de seleção múltipla com base 
nos resultados dos testes A/B. 


e Essa funcionalidade deixou de ter prioridade com base na reunião de 
Karen com a equipe de executivos. 


De acordo com a minha experiência, essa é uma parte importante, mas não 
está presente nas anotações feitas nas reuniões de design. Um dos motivos 
para isso é que as pessoas que fazem as anotações (líderes de projeto ou 
pessoas em cargos administrativos) estão acostumadas a anotar somente “o 
quê”: o que foi discutido, o que foi decidido. Se outra pessoa estiver 
fazendo as anotações para você, ajude-a a entender a importância de incluir 
o porquê. Sem essa informação, suas anotações terão muito menos valor no 
futuro. 


Para resumir, fazer anotações é uma parte essencial de ouvir os 
stakeholders. É importante anotar tudo por escrito para que tenhamos um 
histórico sobre o que foi decidido, possamos saber por que tomamos essas 
decisões e evitar ter a mesma conversa duas vezes. Além disso, conforme 
veremos no Capítulo 9, elas são extremamente úteis para fazer o 
acompanhamento posterior. Contudo, as anotações são mais do que somente 
um local para registrar nossas decisões; elas também nos permitem manter 
o foco para sermos articulados em nossa resposta porque não precisaremos 
mais pensar de novo em tudo o que foi dito antes. Com nossas anotações 
em mãos, será muito mais fácil verificar cada feedback recebido e preparar 
a melhor resposta possível. Não importa o tamanho ou a importância da 
reunião, sempre faça anotações. 
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Attendees: Tom, Jim, Sherry, Eric, Hannah 


e Which email sign up form should we use? Inlina or Exposod 
o Inline form pattem is changing (Sherry) 
o New business regs, Jim to send, API meeting next wock 
o Final: Exposed form, blue background (Sherry) 
o Kelly has the final designs 
* Should Buy now add to cart? Or go to product details? Exampio 
o Eric says quick add to cart, like search 
o Uncertain, need to check with Abdul (7) 
e Can we reverse the order of the variants with price? Mocsup 
o Yes (Sherry, Eric) - mobile use case warrants 
e Should we have two counters because of mobile space? Mockuyo 
o Yes (Sherry, Eric) - mobile use case warrants 
o Second counter to be text treatment only, grey, clock icon 
e Duvus ilimako sense for frev shippimy to be in a different place? Oguis 
o No, need to spend time finding the best consistent placement 
o Jim to work on additional mockups 
o 
Example of below item image 


Questions: 


e Are these products Ikely to have reviews? Nf not, should we hide by default? 
e Can we remove “online exclusive"? 
e What about sharing options from featured? Should we use the same sharing options on PDP? 


Action Items 
e Check with Abdul on quick add to car (emailed 2/3) 
e Sherry to ask Kelly to send final designs on sign up form 


For next meeting: 


Are we settied on the colors? The red in particular is very different. 
Can we control the length of the “Why we love à” text? Are there rules? 
“Lis” versus "Was"? 

Review Free shivoina desians again (Jim) 
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Nem sempre faço boas anotações, mas, quando as faço, elas ficam acessíveis (Google Docs), são 
organizadas, específicas, definitivas, passíveis de ação, têm referências e são voltadas para o futuro! 


New Customer Product Team - Desi 
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2 Disemuss Notácation (Animation, persistence) 
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timido é tara tâua s 


Faça o download de um template e de um documento de trabalho para 
registrar as anotações em reuniões acessando o site: 
http://tomgreever.com/resources . 


Faça perguntas 


Um dos desafios ao falar de design com os stakeholders é que, muitas 
vezes, eles não sabem quais são as melhores palavras para expressar o que 
querem dizer. Do mesmo modo que nós, designers, temos dificuldade para 
expressar nossas decisões a eles, eles também têm dificuldade para 
expressar seus próprios raciocínios a nós. Assim, boa parte do processo de 
ouvir nada mais é do que fazer a outra pessoa falar. Precisamos extrair deles 
as palavras que nos ajudarão a fazer um trabalho melhor. Em geral, não será 
suficiente apenas deixar que alguém diga o que tem para dizer e então 
seguir em frente. Precisamos fazer com que eles falem mais, digam de uma 
maneira diferente e expressem seus raciocínios com mais cuidado. 
Conseguimos isso fazendo boas perguntas. 


Eis algumas perguntas comuns que são convenientes em qualquer situação a 
fim de fazer as pessoas falarem mais, ajudando você a entender as sugestões 
ou os feedbacks que elas derem: 


Qual é o problema que você está tentando resolver? 
Como dissemos na seção anterior, não há problema algum em ser direto 
caso não esteja claro o que os stakeholders estão tentando fazer ao darem 
suas sugestões. Simplesmente pergunte a eles de forma direta. 


Quais são as vantagens de fazer isso dessa forma? 


Isso dá aos stakeholders um modo neutro para explicar por que eles 
acham que a sugestão deles é melhor, sem rotular explicitamente que uma 
sugestão é melhor que a outra. Oferecer a eles uma forma de expressar 
essas diferenças revelará muito sobre o que eles acham que seria a solução 
correta. 


O que você sugere? 
Com frequência, os stakeholders dirão que algo deve ser modificado sem 
ter nenhuma ideia de como isso será feito. Ainda que encontrar a solução 
seja o nosso trabalho, dar aos stakeholders uma oportunidade para propor 
algo nos ajuda a entender suas necessidades e dá a eles um contexto para 
que percebam a dificuldade do problema. 


Como isso afetará nossos objetivos? 


Os stakeholders muitas vezes têm nossos objetivos em mente, mas nem 
sempre percebem de que modo o que dizem está associado a eles. Você 
quer que eles sempre associem diretamente os seus designs aos objetivos. 
Muitas vezes, apenas o processo de responder a essa pergunta já os ajuda 
a ver por que a sugestão dada por eles não funcionará tão bem quanto 
imaginavam. 


Onde você já viu isso antes? 
Pedir um material para referência (outros aplicativos e sites) é uma das 
melhores maneiras de perceber o ponto de vista de seu stakeholder. A 
questão não é sugerir que a ideia deles não funcionará se ela ainda não 
existe, mas descobrir se ela tem como base algum padrão de design 
conhecido, utilizado por outro aplicativo ou site. 


O propósito principal ao fazer perguntas é conseguir que seus stakeholders 
expliquem o que eles querem dizer para que você possa ter certeza de que 
entendeu. Fazer perguntas também oferece vantagens que vão além de 
simplesmente fazer com que a outra pessoa deixe mais claro o que elas 


querem dizer. Mesmo que você já saiba o que a outra pessoa está tentando 
dizer, fazer boas perguntas mostra que você está escutando. Ao repetir o 
que elas disseram com suas próprias palavras e na forma de uma pergunta, 
você reforçará a ideia de que entendeu. Isso gera mais confiança. A outra 
pessoa se sentirá respeitada, valorizada e compreendida. Assim como 
ocorre quando deixamos que os stakeholders falem, haverá muito mais 
chances de eles concordarem com você mais tarde se eles se sentirem bem 
por estarem sendo ouvidos agora. 


Repita e reformule 


As palavras que escolhemos para falar de nossos designs podem ajudar ou 
atrapalhar a conversa. Se não estivermos usando o mesmo vocabulário para 
falar de nosso trabalho com outras pessoas, haverá, inevitavelmente, 
expectativas não atendidas, mal-entendidos e confusão ao longo do 
caminho. Nossos stakeholders nem sempre conhecem ou utilizam as 
mesmas palavras que nós empregamos. Encontrar esse território comum 
exige uma atitude de equilíbrio para chegar até onde eles estão, ao mesmo 
tempo que os ajudamos a dar os passos na direção correta, ensinando-os a 
falar de design. Se vamos chegar a um consenso quanto à solução, 
precisamos que todos passem a empregar um vocabulário comum, que 
facilite a compreensão. Parte do processo de ouvir é identificar as palavras 
que nossos stakeholders utilizam para descrever nossos designs e, então, 
repeti-las para que todos possam estar sincronizados. 


Reformule: converta “gostar” para “funcionar” 


O modo mais importante de fazer isso é ajudar nossos clientes para que, em 
vez de falarem do que gostam e não gostam (isto é, de suas preferências), 
eles passem a falar do que funciona e não funciona (isto é, da eficácia do 
design). É muito fácil para alguém simplesmente dizer que não gosta de 
algo. Uma resposta subjetiva como essa não nos dá espaço para considerar 
as preocupações de nossos stakeholders porque não é possível dizer a eles 
que sua opinião está incorreta. Podemos apenas ter uma opinião diferente. 


Em vez disso, procure oportunidades para converter “gosto” para 
“funciona”. Repita o que eles disserem reformulando a declaração de modo 
a manter o foco na eficácia. Você também poderia dar prosseguimento 


fazendo uma pergunta para confirmar o que eles pretendiam dizer ou para 
pedir esclarecimentos adicionais. 


Por exemplo: “Eu entendo que você quer que esse controle de UI seja 
movido para lá, mas por que tê-lo aqui não funciona?” Quando as pessoas 
ouvem suas preocupações expressas com base na eficácia, em geral, elas 
reconhecem que estão apenas demonstrando uma preferência pessoal. 
Talvez você ainda tenha de lidar com a solicitação deles, mas, ao menos, 
chegaremos ao cerne da questão e saberemos como responder a eles de 
modo mais inteligente. 


Isso não significa que devemos dar uma aula aos nossos stakeholders ou 
corrigi-los. O que devemos fazer é reformular a resposta que eles nos derem 
na forma de uma pergunta que os force a falar de uma maneira que seja 
mais conveniente. Se você não tiver certeza, faça perguntas diretas. 
Incentive-os a dizer o que eles acham que não funciona em seu design. Isso 
significa que você também deve se esforçar para riscar a palavra “gosto” de 
seu vocabulário e sempre colocar ênfase na utilidade e na função do design. 


Repita: o que estou ouvindo você dizer 


Outra forma de ajudar nossos stakeholders a se comunicarem com mais 
clareza é repetir o que eles disserem usando palavras que sejam mais 
relevantes em uma discussão sobre design e UX. Como não esperamos que 
eles saibam todas as “palavras corretas” para descrever nossos designs, 
devemos ouvir o que eles dizem e traduzir para um vocabulário que será o 
nosso território comum. Começar com a frase: “O que estou ouvindo você 
dizer...”, é a melhor abordagem para isso, pois enfatiza que estamos 
ouvindo nossos stakeholders, entendemos o que eles estão dizendo e, agora, 


vamos confirmar, expressando o que foi dito com nossas próprias palavras. 
Eis um exemplo: 


Stakeholder: Não gosto da aparência dos botões desativados. Não tenho ideia do 
motivo pelo qual não funcionam! Devemos adicionar algum texto de ajuda ou uma 
dica de contexto, ou algo assim. 


Designer: O que estou ouvindo você dizer é que você não acha que um controle 
segmentado seja a melhor opção nesse contexto porque o usuário não entenderá 
por que as opções desativadas não estão disponíveis a ele. Está correto? 


Macacos Crianças 


Por que Gatinhos não está disponível? Ensinar nossos stakeholders a chamar isto de “controle 
segmentado” sem menosprezá-los pode ser conveniente para avançar em direção a um vocabulário 
compartilhado. 

Repetir o que nossos stakeholders dizem, usando termos que sejam mais 
convenientes para a discussão, é um grande passo em direção a uma 
linguagem comum, sem nos mostrarmos condescendentes nem parecer que 
os menosprezamos por usarem as palavras incorretas. Você precisa 
encontrar o equilíbrio adequado para ajudá-los, sem fazer com que eles se 
sintam tolos. Podemos ajudar nossos stakeholders a serem mais eficazes 
repetindo o que eles disserem, usando palavras que sejam mais apropriadas. 


Eis alguns exemplos de como podemos compor nossas respostas de forma a 
apresentar um vocabulário que será compartilhado com os stakeholders: 
Stakeholder: Aquele botão precisa ser movido para cá. 
Designer: Nós colocamos a chamada à ação deliberadamente acima do fold. Por 
que você acha que ela deveria ser movida? 
Stakeholder: É muito difícil ver essa seta. 


Designer: A advertência foi feita para ser sutil, de modo que a atenção não seja 
desviada do conteúdo. Você acha que a seta é necessária para a compreensão do 
usuário? 
Stakeholder: Esse menu é difícil de usar. 
Designer: Estamos usando a lista suspensa nativa do sistema, mas poderíamos 
criar um controle personalizado. 
Lembre-se de que uma parte importante ao ouvir é reformular e repetir o 
que nossos clientes disseram para que possamos confirmar que estamos 
sincronizados e sabemos muito bem qual é a melhor forma de responder. 


Vamos rever como é o processo de ouvir o feedback dos stakeholders para 
um design. Não será possível nos comunicarmos com eles de modo eficaz 
se nós não os ouvirmos nem entendermos totalmente o que eles estão 
dizendo. Há várias maneiras implícitas de ouvir, por exemplo, deixar que 
eles falem o quanto precisarem, tentar ouvir o que não está sendo dito e se 


esforçar para descobrir qual é o verdadeiro problema que eles estão 
tentando resolver. Depois disso, faça uma pausa de alguns segundos a fim 
de garantir que eles terminaram de falar. No entanto, há também várias 
habilidades explícitas que podem ser empregadas para sermos melhores 
ouvintes do feedback para o nosso design. Fazemos boas anotações, 
registrando por escrito o que foi decidido. Fazemos perguntas para 
esclarecer e melhorar a nossa compreensão. Além disso, repetimos e 
reformulamos o que os stakeholders disserem para ajudar a estabelecer um 
vocabulário compartilhado e termos um território comum. Tudo isso 
contribui para que sejamos melhores ouvintes, nos ajuda a entender o que 
está sendo comunicado e permite que formulemos a melhor resposta 
possível. Você poderia achar que agora é hora de dizer a eles o que você 
acha, mas não é. Antes disso, precisamos adotar a mentalidade correta. 


[5] 


Assuma a mentalidade correta 


À reunião 
Fazer o 


Entender Ouvir Responder follow-up 
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Você pôs sua alma nesses designs. Investiu todo esse tempo para pensar no 
ponto de vista de seus stakeholders. Além disso, acabou de dedicar a 
melhor parte de sua capacidade mental ouvindo-os falar das razões pelas 
quais eles acham que seus designs não funcionam tão bem quanto você 
imagina. Seria tentador (e até mesmo lógico) pensar que, agora, seu 
caminho está livre para você se lançar em um discurso épico sobre 
usabilidade e falar com extrema eloquência sobre padrões de design e 
dados, mas não é verdade. Antes de alcançar o ponto em que não há mais 
volta, você deve assumir a mentalidade correta. Deve adotar uma atitude 
que ajudará você a ser articulado. É necessário que você saiba qual é a sua 
função, deixe seu ego de lado e sempre comece com um “sim”. Além disso, 
você deve desenvolver uma persona positiva, que incentive as pessoas a 
confiar em você para a solução. Assim que tiver assumido a mentalidade 
correta, você poderá preparar a sua resposta seguindo um padrão chamado 
“Agradeça, Repita, Prepare”. O propósito deste capítulo é ajudar você a 
estar mentalmente preparado para assumir a responsabilidade de articular 
(explicar) as decisões de design. Formular uma resposta eficaz como essa 
exige um pouco de exercício mental. 


Saiba qual é a sua função 


Assumir a mentalidade correta começa com a compreensão de sua função 
na discussão. Acredito que há um mal-entendido comum sobre a função de 
um designer nessas reuniões. Em geral, nós nos vemos nessas reuniões 
como alguém que recebe feedbacks. Achamos que devemos receber 
críticas, defender o nosso trabalho ou revidar. Muitas pessoas comparam 
essa situação às vendas — estamos oferecendo algo para alguém, como um 


vendedor que anda de porta em porta, esperando que comprem. Outras 
vezes, as pessoas falam da reunião como se fosse uma guerra — há batalhas, 
vencedores e perdedores. Porém, nada disso representa um entendimento 
saudável de nossa função e não nos ajudará a adotar a mentalidade 
necessária para sermos bem-sucedidos. 


Nosso trabalho não é apenas absorver o que for lançado sobre nós — nos 
prepararmos para uma infinidade de mudanças que precisam ser 
gerenciadas —, mas orientar a conversa para uma direção positiva e sermos 
os grandes mestres de um ótimo design. Achamos que estamos na reunião 
para receber feedbacks, quando, na verdade, estamos lá para ser um 
facilitador da conversa sobre o design. Estamos lá para conduzir uma 
discussão sobre soluções, e não para empurrar o nosso trabalho garganta 
abaixo para que todos o engulam. Devemos ouvir, analisar, processar e 
transformar as informações recebidas em algo mais útil. Nossa expectativa 
deve ser receber o que nossos stakeholders nos derem e devolver a eles 
como algo melhor do que era antes. Uma mentalidade como essa nos 
permite responder de forma mais objetiva. 


Renuncie ao controle 


Não importa o que pensamos, em geral, não temos a palavra final quando se 
trata de nossos designs. Temos muito que dizer no processo, mas, no fim 
das contas, sempre haverá alguém que poderá falar mais alto que nós. Pode 
haver até mesmo uma equipe inteira de pessoas que discorde das soluções 
que propusemos! Quanto mais cedo você perceber isso, mas rápido você 
verá a importância de aprender a influenciar as pessoas com suas palavras. 
Você não pode forçá-las a concordarem com você. Não haverá nenhuma 
escolha que não seja encontrar um melhor caminho. 


Quando reconhecemos que não temos o controle sobre o resultado 
definitivo, nossa mentalidade muda, evidenciando o quanto precisamos nos 
comunicar bem para preservar a saúde da experiência do usuário. Renunciar 
ao controle permite que você tenha uma liberdade emocional para se manter 
calmo, sem encarar tudo como se fosse pessoal. 


Como isso funciona na prática? Basta assumir a atitude de que o seu 
trabalho não pertence a você. E simplesmente reconhecer que você não 
pode controlar tudo. E admitir que você precisa da ajuda de outras pessoas 


para proporcionar a melhor experiência possível aos usuários. É treinar a 
mente para poder dar dois passos para trás, sair de sua bolha e caminhar 
para o outro lado da mesa para se sentar com o seu stakeholder. Se você 
tiver empatia pelo ponto de vista de seus stakeholders, será muito mais 
natural permitir que o feedback deles exista de forma separada de seus 
próprios interesses pessoais. Se puder convencer a si mesmo disso, você 
estará em uma posição muito mais apropriada para discutir seus designs 
com outras pessoas. 


Os stakeholders representam o nosso trabalho 


Como facilitadores de uma discussão sobre design, também temos parte da 
responsabilidade em ajudar nossos stakeholders a se preparar para suas 
próprias reuniões. Não somos meros facilitadores passivos passando o 
microfone ao redor da mesa. Nossa função também é garantir que nossos 
stakeholders tenham o que precisam para representar o nosso trabalho 
diante de outras pessoas. Devemos dar a eles as ferramentas e o vocabulário 
para que sejam bem-sucedidos nessas conversas também. 
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E comum que alguém saia de nossa reunião e vá falar com outra pessoa a 
respeito de nossos projetos. As pessoas podem ir para outra reunião com 
outros executivos, talvez encontrem alguém que pergunte sobre o projeto no 
corredor ou podem ir para casa e conversar com suas(seus) esposas(os) | 
Qualquer que seja a situação, elas serão questionadas sobre os motivos de 
termos tomado as decisões que tomamos. Se elas próprias não estiverem 
preparadas para explicar, é provável recebermos uma mensagem pedindo 
para fazer alterações. Precisamos preparar nossos stakeholders para que 
sejam bem-sucedidos, de modo que possam se sentir confiantes para 
representar o nosso trabalho diante de outras pessoas. 


Cobrança sem representação 


Em um de meus primeiros trabalhos como designer, minha gerente levava o 
meu trabalho de design e o apresentava em uma reunião executiva semanal, 
com gerentes das áreas de vendas, marketing e serviço de atendimento aos 
clientes. O padrão que eu percebia era sempre o mesmo: ela saía dessa 
reunião trazendo mudanças, eu voltava para a minha escrivaninha para fazer 
as alterações, e o ciclo todo se reiniciava. Durante esse processo, eu tinha a 


impressão de que boa parte do meu raciocínio bem-intencionado era jogado 
fora, eu tinha bons motivos para fazer o que havia feito, e esses motivos 
aparentemente não eram respeitados no processo. Expressei esse sentimento 
para a minha gerente, que sugeriu que eu participasse pessoalmente da 
próxima reunião. 


Descobri que essa reunião era um vale-tudo, no qual qualquer pessoa com 
um par de olhos e uma opinião podia dar feedback sobre o meu trabalho. 
Como eu estava presente, pude explicar por que havia feito o que fiz, e a 
maior parte das opiniões foi perdendo a força. Bem, é verdade que você 
poderia argumentar que minha gerente falhou ao permitir que uma reunião 
como essa servisse de base para o nosso processo de design. No entanto, o 
que eu aprendi é que, se eu pudesse fornecer o vocabulário apropriado para 
a minha gerente e fizesse com que ela entendesse meu design corretamente, 
seria mais provável que ela fosse para aquela reunião e representasse o meu 
trabalho de uma maneira que promovesse um consenso geral. Sem a certeza 
de haver compreendido o meu trabalho, ela estava sujeita a ceder diante de 
todo e qualquer feedback que chegasse até ela. 


Aumentando a confiança 


Em outro projeto, eu estava trabalhando como consultor, e meu cliente era o 
diretor de engenharia. Como ele era engenheiro e não tinha experiência com 
equipes de design, certifiquei-me de ser bem claro acerca de nosso 
processo: começaríamos entendendo os usuários e os casos de negócio e, 
em seguida, passaríamos para a criação dos fluxos de usuário. Em algum 
momento, nossos raciocínios seriam convertidos em wireframes de baixa 
fidelidade e mockups. Ele concordou com esse processo, mas, apesar disso, 
toda semana ele reclamava que não estávamos fazendo o suficiente. “Onde 
estão os designs?” — perguntava ele. Eu o lembrava de nosso processo 
novamente, ele concordava, e nós continuávamos. 


Lá pela quarta semana, ele realmente ficou irritado. “Vocês estão 
trabalhando há um mês e ainda não fizeram nada!” Fiquei chocado. Ele 
havia participado de todas as reuniões, aprovado todos os fluxos de usuário 
e dado feedbacks. “Onde estão os designs?” — repetia ele. De seu ponto de 
vista, ele nos tinha contratado para criar designs para um aplicativo, e nós 
não estávamos entregando isso. No calor da conversa, ele admitiu o 


seguinte: “Toda semana, quando vou para a reunião com a liderança de 
nível mais alto, não tenho nada para mostrar a eles.” Bem, isso não era 
exatamente verdade — sempre dávamos algo para que ele pudesse mostrar —, 
mas o fato é que ele não tinha confiança em sua capacidade de apresentar 
algo como fluxos de usuário. Havíamos feito um péssimo trabalho no 
sentido de dar a ele aquilo de que ele precisava para representar o nosso 
trabalho. 


Ele realmente se importava com os designs? Sem dúvida, mas o que era 
realmente importante para ele era se mostrar competente diante de seus 
colegas e superiores em uma reunião semanal. Perceber isso nos permitiu 
mudar nossas prioridades; assim, toda semana, dávamos algo que ele 
pudesse apresentar de modo confiante, como se fosse um trabalho que ele 
mesmo tivesse feito. Se não fizéssemos isso, nosso projeto corria o risco de 
ser cancelado. 


Portanto, parte de nossa função é fornecer as ferramentas e o vocabulário 
necessários aos stakeholders para que eles representem o nosso trabalho 
diante de outras pessoas. Se conseguirmos que eles se sintam confiantes 
para representar bem o nosso trabalho — se eles realmente entenderem o 
nosso raciocínio a ponto de falar dele para outras pessoas —, é mais provável 
que, como resultado, eles nos deem seu apoio. Nosso raciocínio às vezes 
funciona de modo inverso nesse caso. Buscamos a aprovação deles, quando, 
na verdade, precisamos dar as ferramentas e o vocabulário de que eles 
precisam para representar o nosso trabalho diante de outras pessoas. Essa é 
a nossa função. 


Deixe o seu ego de lado 


Assumir a mentalidade correta também diz respeito a se lembrar de deixar o 
seu ego de lado. Devemos nos desassociar de nossas ideias e ambições, de 
um modo que permita que outras pessoas contribuam para o projeto sem 
que fiquemos cegos às suas sugestões. Não podemos pensar que somos os 
únicos a ter boas ideias, que temos todas as melhores soluções possíveis ou 
que há apenas uma maneira (a nossa) de atingir os objetivos. Nossos egos 
podem prejudicar nossa capacidade de responder aos stakeholders de modo 
eficaz. 


No entanto, há uma tensão nesse caso. Nossa expertise em design sugere 
que devíamos recomendar as melhores soluções. Queremos que nossos 
stakeholders acreditem que sabemos o que estamos falando. Nossa 
expertise e nossas recomendações devem ser levadas a sério. Ao mesmo 
tempo, não podemos acreditar que nossas ideias sejam a única solução. Há 
um equilíbrio delicado entre acreditar que temos as melhores ideias e 
reconhecer que elas não são as únicas ideias. O desafio é fazer 
recomendações sólidas, ao mesmo tempo que consideramos seriamente as 
sugestões e as ideias de outras pessoas. É difícil fazer isso. 


O problema com o ego é que é quase impossível vê-lo em nós mesmos. Se 
todos pudessem reconhecer facilmente que estão sendo egoístas, o mundo 
seria um lugar muito mais simples para viver. O sinal vermelho é quando 
você se vê pensando que a sua solução é tão boa que não vê nenhuma 
importância na sugestão de outra pessoa. Em discussões habituais e 
saudáveis, podemos ver a importância da ideia de outra pessoa, mesmo 
quando discordamos. Quando o ego atrapalha, deixamos de considerar essa 
importância. Sempre que você achar que está certo e eles estão errados, 
tome cuidado. Isso não significa que você deva concordar com eles, mas 
somente que talvez seja necessário reavaliar a situação. 


Quando nossos egos nos impedem de ver a importância de outras ideias, 
isso se manifestará na forma de desculpas para justificar por que a sugestão 
de outra pessoa não é válida. Por exemplo, você poderia se ver pensando o 
seguinte: “Eles não entendem de tecnologia”, “Eles não são o usuário a que 
visamos” ou “Eles não sabem nada de design”. Quando você começa a criar 
desculpas para as ideias de outras pessoas usando estereótipos comuns, ou 
quando menospreza a expertise delas, há uma boa chance de que o seu ego 
deve ser culpado. Preste atenção nesses tipos de reações sutis em sua 
própria mente e encontre uma maneira melhor de se posicionar para poder 
formular a melhor resposta possível. Se a única lógica para discordar da 
sugestão de alguém for: “Eles não entendem o meu trabalho”, você não 
conseguirá defender seus argumentos com base nesse tipo de suposição 
genérica (e egoísta). Ao deixar o seu ego de lado, você criará o espaço 
necessário para formular uma resposta que será baseada na realidade e na 
lógica, em vez de se basear em uma opinião ou em estereótipos. 


Deixar o seu ego de lado faz com que você fique menos na defensiva e, 


desse modo, estará mais bem preparado para responder de forma adequada. 
Deixar o ego de lado ainda é uma luta diária para mim. Não há nenhuma 
pílula mágica. Exige um esforço consciente, lembretes de sua equipe e 
prática. Portanto, faça o melhor que puder para deixar o seu ego de lado. 
Isso permitirá que você tenha a mente aberta, ficando em uma posição 
muito mais favorável para responder às pessoas de cujo suporte você 
precisa para ser bem-sucedido. 


Comece com um SIM 


Uma das barreiras para uma comunicação eficaz surge quando as pessoas 
veem umas às outras como se estivessem em equipes opostas. É fácil haver 
uma mentalidade do tipo “nós versus eles” ao discutir o design com alguém 
que não seja um designer. Um de nossos trabalhos como bons 
comunicadores é lembrar e reforçar a ideia de que estamos todos juntos 
nisso € visamos aos mesmos objetivos. 


Não há melhor maneira de promover essa atmosfera de colaboração do que 
sempre começar com um SIM. 


O conceito de começar com um sim foi apresentado a mim por um de meus 
orientadores e ex-chefes, Dave Ferguson. Dave e eu trabalhamos juntos por 
vários anos nos subúrbios de Chicago. Quando ele estava começando a 
trabalhar como líder, as pessoas tam até ele com grandes ideias que ele 
sabia não serem possíveis. Em vez de dispensá-las prontamente, ele preferia 
dizer sim. Dave percebia que as pessoas ficavam mais motivadas, sentiam- 
se mais capazes e mostravam paixão quando suas ideias tinham permissão 
para ter prosseguimento. Mesmo que não atingissem totalmente o objetivo, 
era muito melhor dar poder às pessoas para que fizessem grandes trabalhos, 
em vez de desestimulá-las. Dave dizia o seguinte: “Aprendemos que, se 
quisermos nos envolver com ideias inovadoras e criativas, devemos 
“começar com um sim”” 2 2 Dave faz referência a um artigo da revista Fast 
Company intitulado “My Greatest Lesson” (Minha maior lição), de 
Katherine Hudson. Nesse artigo, ela diz o seguinte: “Quando alguém 
apresenta um desafio a você, não pense em todos os motivos pelos quais 
você não pode realizá-lo. Em vez disso, diga “Sim!” Em seguida, descubra 
como você o fará”. Esse é o princípio fundamental para começar com um 


sim. 

Esse princípio também tem suas raízes na comédia de improvisação. Uma 
regra comum na improvisação é que um ator sempre deve concordar com o 
outro: o que quer que um deles traga como tema, o outro deve dar 
continuidade. Por quê? Porque, se um ator disser não, ele arruinará 
totalmente o esquete; eles não irão a lugar nenhum. Adivinhe só! Nossas 
reuniões com os stakeholders também são improvisações. Se esperarmos que 
eles avancem para uma direção positiva, é essencial que sempre comecemos 
com um sim. 


Desenvolvendo um reflexo para o sim 


Começar com um sim significa que você sempre iniciará sua resposta com 
uma afirmação positiva sobre a ideia ou a solicitação da outra pessoa 
usando a palavra “sim”. É uma mentalidade que pressupõe que essa pessoa 
não está errada. Ela tem tanto potencial para ter boas ideias quanto você e é 
uma parte importante do processo. Dave chama isso de “reflexo para o 
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sim. 


A maioria de nós tem um “reflexo para o não” para ideias novas e criativas que 
pareçam ser impossíveis. Mas você pode mudar isso... Da próxima vez que alguém 
vier com uma nova oportunidade, certifique-se de que a primeira palavra que saia 
de sua boca seja sim.... A mentalidade do sim dá às ideias ousadas, aparentemente 
impossíveis, uma chance de viver e de respirar e, às vezes, de serem 


implementadas de modo parcial ou total E 


O propósito de aprimorar o seu “reflexo para o sim” não é ceder diante de 
qualquer solicitação feita pelos nossos stakeholders nem deixar 
simplesmente que eles façam o que quiserem. O objetivo é criar um espaço 
em que todos reconheçam que estão na mesma equipe, buscam os mesmos 
objetivos e podem trabalhar juntos a fim de encontrar a melhor solução. 
Conforme escreve Dave, isso dará mais tempo para você entender: 


Treinar a si mesmo para ter o reflexo do sim não faz com que você realmente se 
comprometa a implementar a ideia. Antes que um “Sim” faça com que você se 
comprometa a fazer algo, na verdade, ele faz você ganhar tempo para descobrir 
como fará isso acontecer. Com frequência, dizemos sim e, então, paramos para 
reorganizar e considerar as possíveis vantagens e implicações da oportunidade. 
Começar com um sim faz com que você tenha tempo para descobrir se realmente 
poderá fazer isso... Não estamos defendendo a ausência de limites; estamos 


descrevendo como a inovação acontece. E a inovação acontece nos lugares em 


que raramente se ouve um “Não”... 2 


Começar com um sim é muito mais fácil quando você concorda com a 
sugestão da outra pessoa. “Sim, essa é uma ótima ideia. Concordo 
totalmente que esse controle deve ser um link textual em vez de ser um 
botão.” É mais fácil ainda quando a outra pessoa pode fazer o trabalho que 
está sugerindo, por exemplo, é um outro designer da equipe. “Sim, vamos 
fazer isso! Por favor, vá em frente e atualize a documentação para que 
reflita esse novo design. Boa ideia!” 


No entanto, nem sempre é fácil dizer sim quando discordamos. Se você 
compreende o problema que seu stakeholder está tentando resolver, porém 
discorda da solução proposta, começar com um sim pode soar como: “Sim, 
concordo totalmente com você de que precisamos reconsiderar o 
posicionamento desse controle de UT”. Não estamos dizendo que a solução 
exata proposta por ele está correta e faremos a implementação dessa forma. 
Estamos apenas concordando com o problema porque é possível que ainda 
haja outra abordagem para resolvê-lo. 


Começar com um sim também é um modo eficaz de envolver nossos 
stakeholders nas decisões quando achamos que não é possível fazer o que 
eles querem. Nessas situações, pode ser tentador dizer não diretamente, 
mas, em geral, é melhor começar com um sim e ajudá-los a entender o 
custo-benefício. Por exemplo, a mudança que eles estão sugerindo exigirá 
mais tempo ou dinheiro do que a sua equipe dispõe, e você sabe que não 
será possível, mesmo que todos concordem. Nesse caso, começar com um 
sim pode soar da seguinte forma: 


Sim, concordo que a interação para “adicionar no carrinho de compras” deve ser 
atualizada. Com uma versão a ser lançada na próxima semana, teremos de adiar a 
implementação do novo template de pesquisa para que possamos incluir isso. Você 
concorda? 
Você começou com o pé direito e permitiu que eles participassem do 
processo de uma forma positiva. Muitas vezes, as pessoas simplesmente 
não compreendem tudo que está implicado em nossas decisões. Começar 
com um sim as convida a fazer parte da decisão, de modo que elas possam 
nos ajudar a conduzir o processo. 


Sim, você tem razão ao dizer que nossa documentação não está como deveria ser, e 
precisamos corrigir isso. Se você estiver disposto a me ajudar a supervisionar essa 
parte do projeto e conferir a documentação existente, acho que poderemos 
reorganizar nossas prioridades para fazer isso acontecer. 
Apresentar ideias sem assumir nenhuma responsabilidade é um problema 
comum. As pessoas que estão do lado de fora farão críticas sobre assuntos 
dos quais elas têm uma visão limitada. No entanto, se você der uma chance 
às pessoas de fazerem parte da solução, elas pedirão que você explique ou 
verão como a sugestão que deram causará impacto a todos os demais. 
Qualquer que seja o caso, você manteve uma atitude positiva e ajudou as 
pessoas a verem que as opiniões delas são valiosas e apreciadas. 


Às vezes, basta começar com um sim para conquistar a confiança necessária 
para seguir em frente, sem nem mesmo precisar de mais discussões. Muitas 
vezes, nossos stakeholders somente querem saber que valorizamos o tempo 
e o feedback deles. Começar com um sim pode ter como efeito desarmar a 
pessoa o suficiente para mostrar que você está escutando, além de abrir a 
possibilidade de ela poder confiar em você para a solução. O sim pode ser 
uma palavra mágica, capaz de dar vida a algo. 


Eu estava em uma reunião com várias pessoas, incluindo o presidente da 
empresa. Ele começou a implicar com uma parte específica do design. Era 
uma parte importante da experiência do usuário, mas seu feedback envolvia 
sugestões muitos específicas sobre o posicionamento, a cópia do texto, a cor 
e a interação. Embora eu estivesse satisfeito em resolver suas preocupações, 
seu feedback parecia estar fora do lugar. Por que um executivo se 
importaria tanto com esses pequenos detalhes? Em vez de entrar em uma 
discussão sobre isso, eu disse: “Sim, concordo com você de que precisamos 
reconsiderar a implementação desse menu”. De repente, ele parou e disse: 
“Ótimo, eu sei que vocês encontrarão a solução correta”. 


Perceba que, na verdade, ele não queria discutir os detalhes mínimos do 
design. Pensando retrospectivamente, é provável que ele estivesse “apenas 
conversando”; ele viu algo, tinha uma sugestão e a apresentou. Ele sabia 
que trazer à tona todos aqueles detalhes não era o trabalho dele. Assim, o 
que, à primeira vista, parecia ser uma série de sugestões incomuns ou 
preocupantes, na verdade, era apenas uma conversa casual. Meu acordo 
com ele o fez lembrar que ele poderia confiar em nós para a solução. Ele 


queria ter certeza de que estávamos ouvindo o que ele dizia e estávamos 
considerando o seu feedback. Depois disso, ele ficou satisfeito em deixar 
que fizéssemos o nosso trabalho. Começar com um sim reforçou isso e nos 
permitiu que déssemos prosseguimento à reunião. 


Colocando em prática 


Começar com um sim é uma das táticas mais simples que você pode aplicar 
nas discussões sobre o seu trabalho no momento. Tudo que você deve fazer 
é iniciar a sua resposta com a palavra “sim”. SÓ isso. 


Às vezes, as pessoas me dizem que se sentem desconfortáveis. Eu 
compreendo. Começar uma sentença com sim quando você não o faria 
normalmente nem sempre soa coloquial. No entanto, pelo fato de eu ter 
posto isso em prática por muitos anos, posso dizer que será cada vez menos 
desconfortável quando se tornar um hábito. O desconforto é sentido muito 
mais por quem fala do que por aquele que ouve. Assim que você se 
acostumar a começar com um sim, esses sentimentos se dissiparão e isso 
passará a vir naturalmente. 


As pessoas também me perguntam se elas devem realmente utilizar a 
palavra “sim” ou se podem apenas usar uma linguagem positiva para 
comunicar a mesma ideia. Meu conselho é usar realmente a palavra “sim”. 
Embora você deva usar qualquer linguagem com a qual se sinta mais 
confortável ou que acha ser mais apropriada para a situação, com base em 
minha experiência, posso dizer que a palavra “sim” é mais eficaz do que 
outras abordagens semelhantes. Você não é obrigado a usar a palavra “sim”, 
mas acredito que, se fizer isso, você será mais eficaz. 


Por fim, as pessoas muitas vezes me perguntam como poderão dizer sim 
quando discordarem do que o stakeholder estiver falando; portanto, deixe- 
me explicar com mais clareza. Começar com um sim não é uma questão de 
dizer sim quando, na verdade, você quer dizer não. Não é um truque 
psicológico para enganar as pessoas, fazendo-as concordarem conosco. 


* Você deve concordar em fazer as alterações que eles pediram se você não tem 
a intenção de fazê-las? Não, definitivamente, não. Isso se chama mentir. 


e Você deve fazer com que eles pensem que há um consenso, quando, na 
verdade, vocês discordam? Não, isso seria falsidade. 


* Você deve dizer que a ideia deles é ótima quando, na verdade, você a acha 
péssima? Bem, minha mãe sempre dizia que, se você não pode dizer algo 
agradável, não deve dizer nada, mas essa também não parece ser uma 
ótima maneira de começar com um sim. 


Em vez disso, começar com um sim é uma questão de lembrar às pessoas 
das áreas em que concordamos, antes de chegar às partes das quais 
discordamos. Trata-se de demonstrar que estamos todos na mesma equipe e 
seguimos na mesma direção, mesmo que tenhamos ideias diferentes sobre 
como chegar lá. Além disso, é uma maneira muito eficaz de comunicar que 
valorizamos as contribuições, o ponto de vista e as ideias de nosso 
stakeholder. 


Há dezenas de maneiras pelas quais você pode começar com um sim, sem 
realmente se comprometer com nada. Eis algumas: 

* Sim, essa é uma questão muito boa. 

* Sim, obrigado por compartilhar o seu ponto de vista. 

* Sim, concordo que precisamos resolver isso. 

* Sim, sem dúvida, há algumas maneiras de melhorar isso. 

* Sim, devemos decidir qual é o melhor caminho daqui para a frente. 

* Sim, eu entendo o que você quer dizer. 
Uma ressalva é evitar que a palavra “sim” seja seguida de “mas”. O fato é 
que “Sim, mas...” é somente outra maneira de dizer não, e a maioria das 
pessoas ouvirá isso dessa forma. Até mesmo “Sim, no entanto...” transmite 
uma ideia parecida. Tenho constatado que, muitas vezes, podemos 
simplesmente deixar de fora o “mas” ou o “no entanto” e, apesar disso, a 
frase ainda funcionará. Em vez de “Sim, mas nossa equipe analisou isso”, 
bastaria dizer “Sim, nossa equipe analisou isso”. 
Recebo feedbacks mais positivos das pessoas sobre esse conceito do que de 
outras ideias que estão neste livro. Assim, se você não guardou mais nada 
do que foi dito nestas páginas, lembre-se de sempre começar com um sim. 
O risco é baixo. Experimente e veja por conta própria. 


A medida que desenvolver seu reflexo para o sim, lembre-se do seguinte: 


e Começar com um sim reforça a ideia de que todos estão na mesma 
equipe e facilita a colaboração. 


e Permite que você esteja aberto a novas ideias, mesmo que não tenha 
certeza de como funcionarão. 


e Mantém a discussão aberta, fazendo você ganhar tempo para encontrar a 
resposta apropriada. 


e Dá a você a oportunidade de considerar as ideias, levando em conta as 
limitações e os recursos. 


e Desloca a responsabilidade pelas novas ideias a outras pessoas, fazendo 
com que elas participem da solução. 


* Reforça os laços de confiança com os stakeholders, mostrando que você 
valoriza o que eles disserem. 


Crie uma persona positiva 


Trabalhar com stakeholders será mais desafiador se não tivermos um bom 
relacionamento com eles. Ao participar de uma reunião, devemos supor o 
pior, nos preparar para uma batalha e levantar a guarda para nos proteger 
contra feedbacks negativos. Podemos ficar na defensiva, e isso se reflete 
tanto em nossa postura como em nossa resposta. Com o tempo, essa atitude 
pode evoluir a ponto de adquirirmos uma reputação de sermos 
ambivalentes, desinteressados ou (pior ainda) difíceis de trabalhar. 


Precisamos trabalhar para criar uma persona positiva para que nossos 
stakeholders estejam interessados e atentos ao se reunirem conosco. Temos 
de ser simpáticos, acessíveis e projetar uma imagem de nós mesmos que 
seja atraente para eles. Desenvolver essa persona diz respeito a nos 
apresentar com uma luz que reflita nossas melhores qualidades e demonstre 
um interesse genuíno em ajudar a outra pessoa. Isso é essencial para obter o 
apoio dela. Uma personalidade mal-humorada ou que se mostre na 
defensiva não servirá para convencer ninguém a concordar conosco. Em 
vez disso, podemos sorrir com confiança, ser autênticos, não nos levar a 
sério demais e mostrar que estamos voltados aos stakeholders e às suas 
necessidades. 


Tenha confiança, não seja arrogante 


Mostrar confiança é importante ao apresentar seu trabalho para outras 
pessoas. Se você tiver confiança em si mesmo e em seus designs, as pessoas 


confiarão e darão mais liberdade a você. Se não mostrar confiança, você 
transmitirá incertezas, levando os stakeholders a questionarem a sua 
solução. Sem dúvida, ter confiança não é uma questão de ser arrogante, 
convencido ou afirmar que você está sempre certo. É saber que suas 
aptidões são valiosas e deixar que isso transpareça em seu tom, na 
linguagem corporal e em sua atitude ao falar de seu trabalho. Ser confiante 
é ter orgulho de seu trabalho, ao mesmo tempo que compreende que você 
não é a única pessoa inteligente na sala. 


Para aumentar seu nível de confiança, considere o seguinte: você conseguiu 
esse trabalho por um motivo. Talvez tenha sido o seu portfólio detalhado, 
seu currículo extenso ou sua experiência de trabalho relevante. Qualquer 
que tenha sido o motivo, seus stakeholders escolheram você para esse 
trabalho. Isso transmite certa dose de confiança, crença em sua expertise e 
uma disposição para deixar que você tome decisões. Embora seja sempre 
necessário trabalhar para conquistar a confiança deles, você já está em uma 
ótima posição para comunicar sua mensagem com confiança. 


Uma forma simples de transmitir essa confiança é sorrir. A maioria das 
pessoas vê um sorriso como uma expressão de felicidade, mas sorrir 
expressa várias outras emoções também: concordância, satisfação, 
apreciação, conexão e, sim, confiança. Quando sorrimos, mostramos que 
esperamos concordar com as outras pessoas, apreciamos o tempo e a 
atenção que elas nos dedicam e confiamos em nossa habilidade para 
resolver problemas difíceis. As pessoas que não se sentem confiantes não 
sorriem; elas parecem preocupadas, apreensivas, chateadas ou distantes. Se 
quisermos transmitir confiança, devemos sorrir o máximo possível. Ao 
participar de uma reunião com os stakeholders, faça um esforço consciente 
para sorrir, mesmo que seja um pouco desconfortável. Sorrir mostrará que 
você está confiante e aumentará o nível de confiança deles no processo. 


Seja você mesmo 


Também é importante aprender a ser você mesmo quando estiver com os 
stakeholders. Ninguém gosta quando tem a sensação de que a outra pessoa 
está sendo falsa. Somos melhores quando somos nós mesmos. Ficamos 
relaxados, somos naturais e conseguimos pensar com mais clareza. Com 
muita frequência, os designers assumem um ar de superioridade em uma 


reunião. Eles se mostram arrogantes para se proteger contra feedbacks 
negativos, mas assumir uma atitude como essa apenas fará o tiro sair pela 
culatra. Em vez disso, utilize seus pontos positivos a seu favor, relaxe e seja 
você mesmo. 


Ser você mesmo também ajuda as pessoas a relaxarem. Elas poderão se 
relacionar mais facilmente com você quando virem como você realmente é. 
Parte do que nos torna ótimos como indivíduos é a nossa maneira única de 
conquistar as pessoas. Cada pessoa é diferente, mas todos têm alguma 
habilidade para lidar com as pessoas. O que é que você faz que leva as 
pessoas a sorrir? Como você chama a atenção de alguém se precisar? Como 
você conquistou o coração de sua(seu) esposa(o) ou venceu a eleição da 
classe no Ensino Fundamental? Quaisquer que tenham sido os seus 
sucessos no passado, utilize essas mesmas características a seu favor para 
projetar uma persona que seja exatamente você. 


Algumas pessoas são espirituosas ou engraçadas. Outras são boas em 
acolher e fazer com que as pessoas se sintam à vontade. Outras ainda são 
ótimas para ouvir e gostam de manter contato dando presentes, elogiando 
ou se lembrando de datas importantes. Qualquer que seja a sua 
característica, você terá uma oportunidade de usar essa dádiva única com as 
pessoas que quer influenciar. Não há maneira melhor de influenciar as 
pessoas do que usar suas tendências naturais para mostrar interesse pelas 
necessidades de seu público-alvo. A questão principal é: relaxe e seja você 
mesmo. Você será melhor e seus stakeholders apreciarão a sua 
autenticidade. 


Não se leve a sério demais 


Às vezes, somos tão sérios com nosso trabalho, nosso projeto ou nossa 
tarefa a ponto de sermos incapazes de relaxar e responder de uma forma que 
nos faça parecer humanos. Agimos como robôs: incapazes de entender um 
comentário descontraído ou demonstrar uma simples gentileza. Quando 
entramos no modo de “preciso fazer o trabalho”, pode ser muito fácil ter 
uma visão restrita e manter um foco excessivo nas tarefas. Isso pode ser 
bom (e realmente eficaz) quando estamos mergulhados de cabeça, criando 
algo incrível, mas será muito menos eficiente com um grupo de pessoas de 
cujo apoio precisamos. Aprenda a relaxar: nem todos pensam tão 


seriamente em seu trabalho quanto você. 


Também devemos ser gentis, descontraídos e até mesmo engraçados no 
meio das pessoas de quem queremos o apoio. Falando de modo simples, 
devemos ser agradáveis. Fazer uso do humor é uma ótima maneira de fazer 
isso. O humor desanuvia situações difíceis e rir diminui a tensão. Quebrar o 
gelo com uma piada inocente ou um comentário descontraído é uma ótima 
maneira de fazer todos relaxarem e se concentrarem no propósito da 
reunião. 


Há um equilíbrio delicado entre saber o que é apropriado, o que é realmente 
engraçado e o que está totalmente fora dos limites. Pode ser bom fazer 
piada sobre o elefante na sala, sobretudo se todos estiverem particularmente 
tensos com ele. No entanto, não será apropriado fazer piadas com uma 
pessoa específica, não importa quão engraçado ou relevante possa parecer. 
Eu acho que piadas bobas ou trocadilhos ruins são bem seguros e eficazes, 
mesmo que provoquem resmungos (ou especialmente por causa disso!). 


Por mais que eu goste de pensar que sou um comediante, não cabe 
realmente a mim aconselhar você quanto ao uso do humor, mas, com a 
exposição adequada e bons exemplos, você poderá aprender a usar o humor 
para fazer as pessoas sorrirem, desarmá-las e fazer com que a discussão 
avance de forma positiva. O objetivo não é fazer todos rirem, mas você se 
divertir consigo mesmo e compartilhar essa atitude com as outras pessoas. 
O humor é uma ótima maneira de não se levar a sério demais com as 
pessoas de cujo apoio você precisa para ter sucesso. 


Volte-se para as outras pessoas 


A última técnica que devemos aplicar é assumir uma postura que esteja 
voltada para outras pessoas. Quando nos alinhamos às necessidades de 
outras pessoas, criamos uma conexão capaz de superar qualquer obstáculo à 
nossa comunicação. 


O inverso, é claro, é ser egoísta, mantendo o foco somente em nós mesmos. 
Do mesmo modo que estamos deixando o nosso ego de lado, também 
devemos voltar nossas mentes para os nossos stakeholders e pensar no que 
eles precisam ouvir para nos dar seu apoio. Não é uma tentativa egoísta de 
mostrar complacência a fim de conseguir o que queremos, mas um olhar 


honesto sobre como podemos falar com eles de uma maneira que os 
conduzirá (e a nós também) ao sucesso. 


Quando eu faço algo que magoa minha esposa, sei que pode demorar um 
pouco para que ela me perdoe e se esqueça do assunto. No entanto, posso 
acelerar esse processo. Tenho certeza de que ela vai me perdoar; portanto, 
posso abordá-la com um sorriso e a suposição de que uma reconciliação é 
possível. Posso ser eu mesmo, sendo honesto quanto às minhas intenções, 
apresentado o meu ponto de vista. Também não preciso me levar a sério 
demais; portanto, sempre quebro a tensão com uma piada ou uma referência 
espirituosa à minha própria estupidez. O tempo todo, minha resposta estará 
voltada às necessidades dela: o que ela precisa que eu faça para nos 
reconciliarmos?? Se eu fizer isso, conseguimos, em geral, superar o 
problema rapidamente e manter o foco no que é mais importante juntos. 


Assumir a mentalidade apropriada exige que estejamos cientes da 
percepção que as outras pessoas têm de nós. Desenvolver uma persona 
positiva é importante para superar os obstáculos, e isso é necessário para 
obter apoio. Podemos garantir que nossos stakeholders trabalhem conosco 
para proporcionar a melhor experiência possível aos usuários se sorrirmos 
com confiança, formos autênticos, não nos levarmos a sério demais e nos 
voltarmos para as suas necessidades e expectativas. 


Mude o seu vocabulário 


À medida que fizer a transição para uma mentalidade com um foco positivo 
para dar uma resposta ótima aos stakeholders, é importante guardar algumas 
informações na memória acerca do que você deve e do que não deve dizer 
no processo. Antes de responder, você deve mudar o seu vocabulário. 


“Você está errado” 


Não diga: “Você está errado”. Ninguém gosta de ouvir que está errado 
(mesmo que esteja), e você só fará com que a pessoa fique na defensiva. 
Lembre-se de que seu objetivo é manter uma atitude positiva e sempre 
começar com um sim. Mesmo dizer diretamente às pessoas que você 
discorda delas pode ser o estopim de uma discussão. Se for necessário 
discordar, encontre maneiras de comunicar essa divergência na forma de 


uma ideia alternativa ou de um ponto de vista diferente. Embora possa 
haver ocasiões em que você deva insistir e defender explicitamente algo em 
que você realmente acredita, quase sempre será melhor projetar uma 
imagem de alguém que está, o máximo possível, alinhado aos stakeholders. 
Deixar que essas oportunidades para uma divergência explícita surjam é 
complicado e, provavelmente, não vale a pena correr esse risco. 


“Do ponto de vista do design...” 


Não comece nenhuma frase com: “Do ponto de vista do design...”, porque, 
em geral, essa é apenas outra forma de dizer: “Do meu ponto de vista”. 
Lembre-se de que o seu ponto de vista não é importante, nós nos 
importamos com o ponto de vista do usuário. Além do mais, soa como se 
você estivesse tentando se mostrar superior a eles com a sua expertise em 
design. Ainda que sua expertise e seu ponto de vista sejam realmente 
valiosos, em geral, não é necessário exibi-los. Nossos stakeholders sabem 
que o que dizemos é do nosso ponto de vista. Às vezes, utilizamos essa 
frase quando queremos dizer: “O motivo pelo qual fizemos isso dessa 
forma...”. Se for esse o caso, diga isso. Você não vai querer criar uma 
separação entre a sua expertise e a expertise dos stakeholders. Estamos 
todos no mesmo time. “Do ponto de vista do design...” não reforça essa 
ideia, portanto, risque-o de seu vocabulário. 


“Gosto” e “Não gosto” 


Não fale do que você gosta ou não gosta; em vez disso, mantenha o foco no 
que funciona e não funciona. Lembre-se de que o nosso interesse está na 
usabilidade e na eficácia da aplicação, e não em nossas preferências 
pessoais. Com efeito, elimine totalmente a palavra “gosto” de seu 
vocabulário. Se você se vir dizendo isso ou perguntado a outras pessoas do 
que elas gostam, pare e se corrija. Vale a pena enfatizar que você não 
deveria ter usado a palavra “gosto”. 


Isso será mais difícil se vocês estiverem discutindo o design visual de uma 
aplicação, em vez de fluxos específicos ou a usabilidade em geral. Se o 
propósito expresso da reunião for revisar o design visual, você ainda terá de 
encontrar meios de comunicar o motivo pelo qual você acha que os designs 
visuais funcionam ou não funcionam, em vez de dizer por que gosta ou não 


gosta deles. Por exemplo, pelo fato de cores e estilos específicos 
contribuírem com a experiência do usuário, você poderá manter o foco de 
seus comentários no modo como o aspecto visual afeta a consolidação da 
marca, a percepção ou a emoção. Nosso objetivo é garantir que a 
experiência do usuário seja consistente, inteligente e agradável. Um foco 
apropriado, evitando a palavra “gosto”, nos ajudará a sermos eficazes em 
nossa resposta. 


Excesso de jargão 


Por fim, evite o máximo possível o uso de um jargão específico da área. Em 
vez disso, encontre palavras que uma pessoa comum possa entender, para 
que todos estejam na mesma sintonia. Em nossa bolha de designers de UX, 
é fácil nos acostumarmos com referências a processos (Agile, scrum, 
sprints), ferramentas (GitHub, Sketch, Axure) ou elementos (accordion, 
CTA, modal) específicos. Muitos stakeholders não compartilham de nosso 
vocabulário da cultura de design, web e aplicações; portanto, antes de 
responder, devemos parar e filtrar nossa resposta, eliminando as palavras 
que possam não estar claras. 


Em vez disso, utilize o conhecimento adquirido por você ao ouvi-los e 
adote as palavras que você percebeu que eles utilizam, conforme vimos no 
Capítulo 4. Essa é a sua oportunidade para repetir e reformular o que eles 
disseram, em um esforço tanto para se comunicar com clareza como para 
ensiná-los a falar de design, mas você não deve começar utilizando palavras 
com as quais os stakeholders não tenham familiaridade. Esteja sempre 
ciente do vocabulário que utilizar e certifique-se de que sejam palavras que 
seus stakeholders entenderão. 


Faça uma transição 


Agora que você já assumiu a mentalidade correta, será necessário fazer uma 
transição para a sua resposta, preparando o seu caminho para o sucesso. 
Você terá a oportunidade de chamar a atenção dos stakeholders, permitindo 
que eles saibam o que esperar. É essencial garantir que seus stakeholders 
ouçam e aceitem sua resposta da melhor forma possível. Essa é a resposta 
antes da resposta. 


Não importa como você decida estruturar a resposta propriamente dita, 
lembre-se de manter essa transição breve. A questão principal não é fazer 
uma longa introdução, mas proporcionar apenas uma transição. Recomendo 
empregar uma abordagem simples chamada “Agradeça, Repita, Prepare”. 
Cada um desses três elementos deve fazer parte de uma frase rápida. 


Agradeça 


Sua primeira atitude deve ser agradecer aos seus stakeholders. É a forma 
mais bem-educada de passar daquilo que eles disseram para o que você 
quer dizer, além de expressar um reconhecimento de que o tempo deles é 
valioso e está sendo apreciado. Sempre queremos que nossos stakeholders 
saibam o quanto apreciamos o tempo e a atenção deles. Eles são o motivo 
de sermos tão afortunados com esse trabalho incrível! Diga uma palavra de 
agradecimento assim que iniciar a transição, do modo mais breve possível. 


Repita 

A seguir, faça um breve resumo do que os stakeholders acabaram de dizer, 
caso ainda não o tenha feito. Com isso, não quero dizer que você deva 
passar por todos os pontos, linha a linha, de suas anotações. Em vez disso, 
diga uma frase que descreva o que eles acabaram de fazer por você, de um 
modo que seja cortês. Isso complementará naturalmente o “obrigado” com 
o qual você já havia começado e lembrará os stakeholders de que você 
estava ouvindo. 


Prepare 


Por fim, diga aos seus stakeholders que você está prestes a responder ao 
feedback dado por eles. Pode parecer óbvio (e é), mas o intuito da transição 
é proporcionar uma continuidade a todos. Por mais que isso pareça ser 
desnecessário, preparar o cenário dessa forma criará a atmosfera apropriada 
e preparará os stakeholders para que ouçam. 


Apenas dizer aos stakeholders que você vai responder não é suficiente. Você 
deve dar algum insight a eles sobre o conteúdo de sua resposta, permitindo 
que eles vislumbrem o que está por vir. Deve dizer a eles não só que você 
vai responder, mas como vai responder e o que planeja dizer. Essa é a 
oportunidade de deixar tudo às claras, de dar uma pista a eles sobre qual 


será o seu feedback a fim de garantir que não haja nenhuma surpresa. Você 
está tentando evitar rodeios, sendo claro e indo direto ao ponto. 


Eis alguns exemplos: 


* “Obrigado por compartilhar suas ideias conosco acerca desse projeto. 
Seus insights são realmente importantes e agradeço por você ter 
revisado tudo isso conosco. Vou repassar todas as questões levantadas 
por você para que possamos discuti-las, mas primeiro gostaria que você 
entendesse como chegamos a essas conclusões...” 


* “Obrigado por compartilhar seu feedback. Agradeço a oportunidade de 
ter revisado tudo isso com você porque é importante que estejamos em 
sincronia. Gostaria de repassar tudo o que você disse, pois há alguns 
pontos importantes acerca dos quais você deve saber de nossas decisões 
com mais detalhes; isso ajudará você a ver como estamos abordando 
esse problema.” 


Esses são exemplos, até certo ponto, genéricos e podem ser usados 
praticamente em qualquer situação, mas você pode perceber como todos 
eles transmitem uma impressão parecida, reforçam a mentalidade de equipe 
e deixam o stakeholder preparado para o que vai vir a seguir. Nas duas 
situações, eu disse ao stakeholder que nossas ideias têm uma explicação que 
vale a pena considerar. Talvez pareça uma fala sem importância, mas a 
prática de dizer a alguém o que eles devem pensar, ou que é provável que 
pensem, na verdade, é muito eficaz. O interessante é que, em geral, as 
pessoas acreditarão no que você disser; portanto, diga que elas concordarão 
com você! Mesmo que não concordarem, ao menos você terá preparado o 
cenário de forma positiva. 


A seguir, apresentamos outros exemplos que mostram como você poderia 
lidar com um feedback mais específico: 


* “Obrigado por apontar as diferenças entre o aplicativo existente e os 
nossos novos designs. Você está certo ao dizer que há alguns pontos 
importantes que devemos considerar, e eu gostaria que você soubesse 
que pensamos muito antes de fazer o nosso design; portanto, gostaria de 
explicar o motivo de termos feito o que fizemos com as views de 
tabela.” 


e “Obrigado por ser direto ao dizer que está preocupado com a nossa 


implementação do fluxo do carrinho de compras e do checkout. Vou 
falar de cada um dos pontos que você levantou porque tivemos alguns 
motivos muito específicos para fazer da forma que fizemos, e eu gostaria 
que você tivesse conhecimento disso. Acho que você concordará que vai 
haver um aumento da conversão assim que entender o nosso processo de 
raciocínio. 


“Obrigado pelo seu ponto de vista sobre a página inicial. Sem dúvida, 
você deu vários feedbacks muito bons, e eu gostaria de passar por todos 
eles, se não houver problema. Nosso raciocínio para o layout está mais 
relacionado à nossa visão de longo prazo e a outras iniciativas que 
esperamos ver no futuro; portanto, é importante que você saiba por que 
abordamos isso dessa forma. 


Eis o ponto principal: não basta simplesmente se lançar diretamente na 
defesa de seu trabalho. Você deve parar para assumir a mentalidade correta, 
manter uma atitude positiva e fazer uma transição elegante para o que vier a 
seguir. 


Todo esse trabalho de preparação compensará. Pode parecer que há muito 
que considerar, lembrar e fazer para uma simples conversa com um 
stakeholder sobre design, mas, na realidade, o processo ocorre com muita 
rapidez. Nosso trabalho é adotar essas práticas e fazer com que se tornem 
um hábito, de modo que sejam transparente durante a discussão. 


Em suma, para adotar a mentalidade correta, devemos: 


Perceber que nossa função não é receber feedbacks, mas conduzir uma 
discussão sobre soluções de design. 


Renunciar ao controle do resultado para que possamos permitir que 
outras pessoas apresentem seus pontos de vista sobre o projeto. 


* Deixar nosso ego de lado para estar aberto às ideias de outras pessoas. 


e Começar com um sim para criar uma atmosfera de consenso e 


cooperação. 


e Desenvolver uma persona positiva para que possamos conquistar as 


pessoas com o nosso estilo único. 


e Mudar nosso vocabulário para evitar contaminar a nossa resposta com 


possíveis falhas de comunicação. 


e Criar uma fase de transição para que possamos preparar o cenário para o 
que estivermos prestes a dizer. 


Finalmente, podemos agora passar para a nossa própria resposta e encontrar 
as melhores maneiras de ajudar nossos stakeholders a verem o nosso ponto 
de vista. A melhor parte é que já existem algumas formas testadas e 
comprovadas para conseguir o apoio de que precisamos. O próximo passo é 
formular uma resposta. 


1 Acredite em mim, isso acontece. 


2 N.T.: Essa e as demais citações deste capítulo foram traduzidas livremente, com base 
no original em inglês. 


3 Dave Ferguson, Jon Ferguson e Eric Bramlett, The Big Idea (Grand Rapids, MI: 
Zondervan, 2007), p. 180. Usado com permissão. 


4 Ibid. 
5 Ibid. A ênfase é minha. 


6 Lavar a louça sempre ajuda. 
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Formule uma resposta 


À reunião 
Fazer o 
Entender Ouvir Responder follow-up 


— e — 4 


Agora que chegamos na hora de realmente responder aos nossos 
stakeholders, precisamos usar tudo que vimos até agora e aplicar 
imediatamente. Responder ao feedback dos stakeholders é uma questão de 
organizar suas palavras de um modo que resulte na melhor resposta 
possível, mantendo o foco no objetivo da reunião: obter o apoio e a 
concordância deles para avançar. Para alcançar esse objetivo, podemos 
dividir a resposta em várias partes básicas. Essa lógica fluirá em conjunto e 
nos possibilitará apresentar o nosso raciocínio de forma a comunicar a 
melhor resposta possível. 


Quando nos comunicamos com as pessoas a respeito do design e esperamos 
conseguir a adesão delas, não será diferente do que ocorre em outras áreas 
em que se almeja uma ação do receptor, por exemplo, nas áreas de 
marketing e publicidade, na política, ou até mesmo em campanhas 
militares. Há um padrão que podemos usar para reproduzir essas outras 
abordagens de comunicação. Como em qualquer bom plano de 
comunicação, precisamos ter um objetivo ou meta, uma estratégia para 
atingir o objetivo, táticas para colocar a estratégia em prática, a mensagem 
para empregar as táticas e, por fim, um modo de induzir o receptor a dar 
uma resposta. Cada parte é realimentada pela outra para nos ajudar a 
alcançar o objetivo. 


Neste e nos próximos dois capítulos, veremos essas partes em detalhes. Por 
enquanto, começaremos definindo inicialmente a nossa estratégia para 
responder. Devemos saber o que queremos dizer para alcançar o nosso 


objetivo de chegar a um consenso. Em seguida, veremos quatro táticas 
específicas para colocar essa estratégia em ação. Essas táticas foram 
personalizadas para as discussões de design e nos dão algumas opções sobre 
como falar de nosso trabalho no contexto da experiência do usuário (UX). 
No Capítulo 7, analisaremos várias das respostas mais comuns usadas no 
feedback de design de UX. Esses modelos ajudarão você a identificar as 
mensagens essenciais relevantes para a sua situação, além de fornecer um 
ponto de partida para a sua resposta. Por fim, no Capítulo 8, reuniremos 
tudo, criando uma resposta que englobará todas as áreas importantes e, em 
seguida, solicitaremos diretamente a concordância de nossos stakeholders. 
É isso que eu chamo de resposta ideal. Se tudo isso parece um pouco 
artificial demais para uma discussão comum, acompanhe-me nesse 
processo, pois precisamos analisar primeiro cada uma das partes em 
separado para que elas fluam naturalmente em um contexto real. 


De modo geral, formular uma boa resposta exige o seguinte: 


º Definir nossa estratégia para responder. O que iremos dizer para sermos 
convincentes? 


* Empregar táticas que nos ajudarão a chegar lá. Como colocaremos a 
estratégia em ação? 

e Identificar respostas comuns e relevantes. Quais mensagens essenciais são 
importantes em nosso contexto? 


* Aplicar um modelo comum e pedir aos stakeholders que concordem. O que 
queremos que nossos stakeholders façam em seguida? 


Uma estratégia de UX para responder 


Já sabemos qual é o nosso objetivo: obter apoio de nossos stakeholders e 
conseguir que eles concordem para podermos avançar. Tudo que dissermos 
deve levar essas metas em consideração. Fazemos isso empregando uma 
estratégia de resposta que nos faça manter o foco nesse objetivo. Vamos 
rever as três perguntas que apresentei no Capítulo 1, as quais ajudarão você 
a ser um melhor comunicador e um ótimo designer. É importante enfatizar 
que, durante todo esse processo, você retomará suas respostas a essas 
perguntas e as usará para ter uma base sobre como responder aos seus 
stakeholders: 


* Qual é o problema que o nosso design resolve? 
* Como o usuário será afetado? 
* Por que essa solução é melhor que a alternativa? 


As respostas a essas três perguntas formam a base para qualquer resposta 
que você der aos stakeholders. Se pudermos comunicar esses três pontos, 
nosso caminho estará preparado para o sucesso. De modo conveniente, 
podemos montar a estratégia de resposta com base em nossas respostas a 
essas perguntas. Com isso, teremos definido os fundamentos para as táticas 
que escolhermos para dar nossa resposta. Vamos ver como cada uma dessas 
perguntas nos fornece uma estratégia clara na hora de responder. 


Apele para um motivo mais nobre 


Nossa primeira estratégia para responder é apelar para um motivo mais nobre. 
Sempre que responder a um feedback de design, você deve sempre tentar 
associar suas decisões a um objetivo, uma métrica ou outro problema que 
estiver resolvendo. É nessa hora que a sua resposta à pergunta Qual é o 
problema que o nosso design resolve? será conveniente. Essa ideia de associar 
suas decisões a uma métrica acordada é um dos passos de uma 
comunicação eficaz, que Dale Carnegie chama de “Apelar para um motivo 
mais nobre” em seu clássico livro de 1936, How to Win Friends and Influence 
People À Acho isso particularmente eficaz nas discussões de design e, com 
frequência, é o ingrediente que falta no portfólio de um designer com 
respeito às técnicas de comunicação. Você quer identificar aquilo com o 
qual seus stakeholders mais se importam e associá-lo à experiência de 
usuário proposta. 


Em qualquer aplicação ou site, temos um conjunto de objetivos acordados, 
métricas, KPIs (Key Performance Indicators, ou Indicadores Básicos de 
Desempenho) ou outros fatores para medir o sucesso. Estamos tentando 
resolver problemas com os nossos designs, e qualquer decisão deve refletir 
isso. Conforme mencionamos no Capítulo 1, ter esses problemas definidos 
no início e uma métrica para avaliar o sucesso será essencial para defender 
seus argumentos junto aos stakeholders. Se você não tiver nenhum objetivo 
ou métrica, escreva-os por conta própria e apresente-os ao stakeholder. 
Ambos precisarão deles se quiserem ter sucesso. 


Muitas vezes, o feedback dado pelos stakeholders para um design não leva 
esses objetivos em consideração no início. As pessoas olham para algo e 
reagem, em geral, sem considerar o propósito original do projeto. Arte e 
design, afinal de contas, têm o intuito de provocar emoções, incitar uma 
resposta e, portanto, a reação automática de seus stakeholders ao seu 
trabalho pode não ser um sinal de falha; eles apenas não estão pensando nos 
objetivos originais. Seu trabalho é manter esses objetivos em primeiro 
plano, lembrando os stakeholders do motivo de vocês estarem ali e fazer 
com que a discussão avance. 


Aumentando a taxa de inclusão no carrinho de compras 


Eu estava trabalhando em um site de comércio eletrônico com o objetivo de 
aumentar a taxa de inclusão no carrinho de compras. Havíamos criado 
algumas interações ótimas, voltadas especificamente para melhorar essa 
métrica, e o design havia sido personalizado com vistas aos desafios de 
logística únicos desse negócio em particular. À medida que os stakeholders 
comparavam a experiência com outros sites populares de comércio 
eletrônico, muitas perguntas surgiam: “Por que esse botão é tão grande? A 
interação realmente tem de usar esse controle em particular? Temos certeza 
de que esse é o texto correto para a chamada à ação?”. Para além do design, 
surgiram perguntas sobre outras métricas: “E quanto ao abandono do 
carrinho de compras? E a conversão geral? Não seriam importantes 
também”? Nessas discussões, pude dar ênfase ao nosso objetivo para a fase 
em questão (aumentar a taxa de inclusão no carrinho de compras) a fim de 
relembrá-los do foco e do motivo pelo qual acreditávamos que essas 
decisões melhorariam esse KPI. Sem essa métrica anteriormente acordada, 
poderíamos facilmente ter permitido que o projeto se transformasse em um 
monstro ao tentar resolver cada preocupação que surgisse, e o resultado 
teria sido uma confusão. Em vez disso, mantivemos nossos designs com um 
foco preciso no problema que nos pediram que fosse solucionado. 


Todavia, mais do que justificar nossas decisões, apelar para um motivo mais 
nobre também pode ajudar você a manter o controle da reunião. Em outra 
reunião com a mesma equipe, a discussão havia se voltado para a 
visibilidade do utilitário de busca da loja e como ele mostrava os níveis de 
estoque da loja nos resultados da busca. Embora essa discussão, de modo 


geral, fosse importante para os negócios, e esse era realmente um problema 
que deveria ser resolvido no longo prazo, não era algo que estávamos 
tentando solucionar naquela fase em particular. Em vez de permitir que essa 
discussão atrapalhasse a reunião, propus adicioná-la como um item 
pendente a ser discutido em uma fase futura e adiar a discussão. Com isso, 
conseguimos manter o controle da reunião. 


Perceba que, às vezes, o assunto ao qual você fica preso não ajudará você a 
atingir seus objetivos; desse modo, será apropriado sugerir que a discussão 
avance, deixando esse problema para ser resolvido depois. Se seu objetivo é 
melhorar a conversão, mas todos ficam discutindo se o indicador de 
carregamento deveria ser um spinner ou uma barra de status, esse é um bom 
sinal de que a conversa, em última instância, não ajudará você. Os spinners 
podem ser importantes, mas não fique preso a eles. Concorde em seguir 
adiante. Sempre que puder associar suas decisões de design aos objetivos 
originais, aos casos de uso ou às métricas da aplicação, você terá ótimas 
chances de defender seus argumentos. 


Represente o usuário 


Nossa segunda estratégia é explicitamente representar o usuário. Talvez isso 
seja tão óbvio que chega a ser facilmente esquecido, mas nossa resposta 
deve sempre representar o usuário de forma tangível e real — ela deve ser 
mais do que apenas uma atividade verbal. Temos de ajudar nossos 


stakeholders a entender nossas decisões respondendo à pergunta: Como o 
usuário será afetado? 


Pensamos muito no usuário de modo natural. Provavelmente, até mesmo 
dizemos “o usuário” em nossas reuniões, mas é importante lembrar que 
nossa função no processo de design não é apenas construir algo que leve o 
usuário em consideração; na verdade, devemos defender os usuários diante 
de nossos stakeholders. Somos os representantes de nossos usuários nessa 


reunião. 


Sua resposta é uma oportunidade para apresentar aquilo que você já sabe 
acerca de seus usuários ao cliente na forma de uma narrativa que gere o tipo 
de empatia necessário para nos levar à ação: tomar a melhor decisão para 
eles. Em vez de manter o foco no funcionamento do sistema, criamos uma 
conexão humana que mostra uma real necessidade sendo atendida. 


Adicionando um botão 


Uma das ótimas características das aplicações web modernas é que elas 
podem atualizar a página sem a necessidade de atualizar e recarregar tudo. 
No entanto, percebi que isso, ocasionalmente, causa problemas aos 
usuários, que esperam ver a página mudar quando escolhem uma opção 
diferente. Se a página não mudar, eles acham que a aplicação não está 
respondendo. Em uma aplicação desse tipo, tínhamos um conjunto de filtros 
que os usuários podiam marcar e desmarcar. A página era atualizada 
instantaneamente, sem nem mesmo precisar de um indicador de progresso; 
alguns dos usuários que observamos, porém, não percebiam que os 
resultados da busca haviam sido atualizados; assim, adicionei um botão 
Done (Pronto) que fechava o painel de filtros e dava a eles um senso de 
completude. 
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O acréscimo de um botão Done (Pronto) deu ao usuário um maior senso de controle, mas, na 
verdade, não fazia nada além de fechar o painel. 

Quando apresentei essa mudança aos nossos stakeholders, tive de justificar 
o acréscimo de um botão que parecia ser desnecessário e, praticamente, não 
fazia nada, mas, apesar disso, ocupava espaço na UI. O modo mais fácil de 
representar o usuário nesse caso seria falando de minhas observações em 
termos gerais: 


Em nosso estudo de usabilidade, as pessoas não percebiam que os resultados da 
busca estavam sendo atualizados automaticamente, portanto, adicionamos o botão 
Done para dar a elas uma forma de mostrar explicitamente que haviam concluído a 
tarefa. 


O melhor seria apresentar a mesma ideia na forma de uma narrativa (ou de 
um caso de uso) que descrevesse uma situação real para os usuários. 


As pessoas se distraem quando fazem compras com o aplicativo, e elas precisam 
sinalizar que acabaram de fazer uma filtragem. O botão Done permite fazer isso e 
dá às pessoas um senso de controle sobre os filtros. 
A melhor opção, porém, seria contar a história de um usuário que seja um 
bom representante para falar por outras pessoas, usando detalhes humanos 
que incentivem uma conexão com suas necessidades. 


Tivemos pais usando o aplicativo na loja, junto com seus filhos. Eles não 
percebiam o resultado sendo atualizado e tocavam a tela várias vezes, se sentindo 
frustrados. Disponibilizar esse botão Done deixará a tarefa mais clara, e os 
produtos serão mostrados a eles mais rapidamente. 
Conforme mencionei no Capítulo 1, observação dos usuários e estudos de 
usabilidade são essenciais para podermos nos comunicar com os 
stakeholders com eficácia e defender o usuário. Você não pode representar 
alguém que jamais tenha conhecido ou observado. Assim, faça o que for 
necessário para sair e observar as pessoas usando o seu projeto. Não são 
necessárias muitas observações para extrair insights relevantes sobre o 
design de sua aplicação ou site. Então, você poderá aplicar esse 
conhecimento em suas reuniões com os stakeholders a fim de representar o 
usuário e defender seus argumentos que explicam por que seus designs são 
a opção correta para proporcionar a melhor experiência possível aos 
usuários. 


Demonstre a eficácia 


Nossa terceira estratégia para preservar a experiência do usuário responde à 
última pergunta Por que essa solução é melhor que a alternativa? e nos coloca 
em posição para obter o apoio de que precisamos para seguir em frente. 
Para isso, nossa resposta deve demonstrar como a solução proposta por nós 
é melhor que as alternativas, incluindo qualquer uma que tenha sido 
sugerida pelos nossos stakeholders. 


Conforme mencionei antes, essa é a parte da discussão em que os designers 
muitas vezes fracassam em defender seus designs de modo apropriado. 
Embora, provavelmente, façamos um bom trabalho para resolver problemas 
e facilitar a vida dos usuários, somos menos inclinados a ajudar as pessoas a 


entender como e por que nossos designs são a melhor abordagem. 
Demonstrar isso de forma deliberada é importante para explicar a 
importância dessa questão. 


Sua resposta é uma oportunidade não só de explicar por que seu design é 
melhor, mas também de mostrar visualmente como e por que seus designs 
farão diferença. Falar é fácil, mas uma figura vale mais do que mil palavras. 
Toda resposta deve manter o foco especificamente nas diferenças entre cada 
design e deve expressar por que a sua solução é a melhor. Mais do que isso, 
você deve mostrar exatamente aos seus stakeholders por que isso é verdade. 
Ser capaz de identificar e expressar essas diferenças é uma habilidade 
importante para articular suas decisões de design. 


Protótipos para convencer 


Um dos itens que podem ser realmente difíceis de entender até estarem em 
um formato utilizável são os fluxos de usuário. Os designers de UX passam 
bastante tempo colocando notinhas adesivas na parede, discutindo o modo 
correto de direcionar um usuário pela aplicação e então as transformam em 
uma série de mockups estáticos. Muitas vezes, uma solução que parece 
fazer sentido na parede de uma sala de reuniões causa uma impressão 
totalmente diferente quando você a tem nas mãos. 


Um aplicativo móvel no qual trabalhei tinha um fluxo bastante complicado 
para os usuários se cadastrarem em uma série de promoções especiais 
porque havia muitas variáveis. O usuário havia feito o acesso a partir de um 
URL especial ou de uma campanha por email? Eram usuários pagantes? 
Tinham uma conta online? Estavam logados? Dependendo da combinação 
de variáveis, o usuário poderia ser direcionado para um entre 
aproximadamente uma dúzia de caminhos distintos. Logo ficou claro que 
esses fluxos eram confusos, mesmo para nós que estávamos fazendo o 
design deles. Depois que a equipe havia concordado com uma solução, 
percebi que estávamos complicando demais e sugeri uma abordagem mais 
simples; meus stakeholders, porém, não estavam convencidos de que todos 
os casos estariam contemplados. 


Em vez de discutir com pedacinhos de papel colados na parede, passei para 
o modo de criação de protótipos e criei uma demo simples, frame a frame, 
de como isso funcionaria. O resultado foi um apoio imediato, como se 


lâmpadas tivessem acendido na cabeça de todos assim que viram a 
diferença. O fluxo original parecia confuso e suscetível a erros assim que o 
vimos diante de nós. O fluxo novo era mais simples e claro. Na verdade, era 
tão simples que era difícil acreditar que não havíamos pensado nessa 
solução antes. Nesse caso, por mais eloquentes que fossem as palavras, 
talvez elas não tivessem convencido ninguém acerca da abordagem correta. 
Simplesmente falar dela não foi suficiente; tive de, realmente, demonstrar a 
eficácia de minha solução. Demonstrar seus designs é uma estratégia 
importante para articular (explicar) as decisões de design. 


Táticas são ações 
Agora que temos nossa estratégia bem definida, o próximo passo é 


empregar táticas que ajudem a colocar essa abordagem em prática. Quando 
falamos de design, sugiro cinco táticas para moldar a nossa resposta: 


1. Exibir uma comparação; 

2. Propor uma alternativa; 

3. Dar uma opção aos stakeholders; 

4. Pedir a outras pessoas que se manifestem; 
5. Adiar a decisão. 


Não há somente uma maneira de aplicar essas táticas. Você poderia optar 
por empregar uma delas ou utilizar todas, conforme a situação. Seu trabalho 
é decidir quais desses métodos serão mais apropriados para defender seus 
designs e ajudarão você a chegar a um consenso. 


1. Exibir uma comparação 


A primeira tática é exibir uma comparação. Você deve levar o design que 
está propondo e as mudanças sugeridas e mostrar aos stakeholders, lado a 
lado, para que as diferenças entre ambos estejam claras. O propósito é 
apresentar uma referência visual que não deixe dúvidas sobre qual é a 
melhor abordagem. Com muita frequência, falamos de design nas reuniões 
usando palavras que não são capazes de demonstrar devidamente o efeito 
que ele terá na experiência do usuário. A ideia, nesse caso, é encontrar uma 
maneira de fazer mudanças rápidas no design e apresentar as duas opções, 


uma ao lado da outra. 


Em geral, faço 1sso diretamente no software de design, usando uma captura 
de tela das duas ideias e colocando-as na mesma moldura, com uma grande 
linha divisória no meio. Talvez eu já saiba qual será o feedback e deixo os 
dois designs preparados para discussão. Meu stakeholder talvez tenha 
insistido na mudança em uma reunião anterior. Volto agora preparado para 
fazer uma argumentação convincente, com recursos visuais que mostrarão 
as diferenças, esperando defender o meu ponto de vista. Não importa como 
você vai fazer isso, mostre as duas opções na mesma view para que seja 
possível discutir com os stakeholders, sem precisar alternar entre abas ou 
janelas distintas. 


Mostre tudo 


Em um dos sites em que trabalhei, havia uma navegação horizontal com 
dois níveis, um abaixo do outro. O segundo nível de navegação era um 
conjunto de filtros que, embora fosse útil, não fazia parte de nossos 
objetivos para o projeto. Era simplesmente um artefato na discussão sobre o 
design: “Vamos mostrar todos os filtros!”. No entanto, um de nossos 
objetivos de design era colocar o máximo possível de conteúdo (nesse caso, 
novos títulos) na área vertical do navegador, em um formato apropriado 
para celulares. Desse modo, otimizamos o design dos blocos de conteúdo a 
fim de garantir que os títulos estivessem totalmente visíveis, incluindo a 
remoção de vários outros elementos que, normalmente, iríamos incluir, por 
exemplo, tags de conteúdo ou o nome do autor. Enquanto trabalhava nisso, 
percebi que esse segundo nível de navegação estava ocupando muito 
espaço; portanto, refiz o design para que tudo coubesse em um único menu 
horizontal. Contudo, fiz isso movendo os filtros para um menu suspenso 
próprio e dando prioridade a alguns dos itens do nível principal. 
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Refiz o design da navegação para que houvesse um só nível, pois colocar os títulos na área vertical 
do navegador era um objetivo importante para esse projeto. 

Quando meu cliente viu isso, ele discordou, perguntando: “Como alguém 
saberá como pode filtrar se não é possível ver os filtros?”. Entretanto, como 
eu sabia que colocar mais conteúdo na área vertical era uma prioridade, 
decidi simplesmente mostrar a ele a diferença, em vez de discutir sobre a 
possibilidade de descoberta das opções. Coloquei capturas de tela dos dois 
designs lado a lado, com uma linha bem grande no meio. Ficou 
imediatamente claro, pela comparação, que o novo design havia nos 
ajudado a atingir um de nossos objetivos para a aplicação. Essa técnica não 
só foi eficaz, como também me poupou tempo e energia por não ter de 
descrever uma decisão de design que foi mais bem comunicada 
visualmente. 


Quando os clientes ou os stakeholders fazem sugestões sobre como alterar o 


seu design, é improvável que você não vá ter ao menos que experimentar e 
mostrar a opção a eles. Você deve, inicialmente, considerar suas 
preocupações e, em seguida, mostrar uma melhor opção. Se você mostrar 
somente a ideia que eles deram isoladamente, é provável que eles acreditem 
que seja a opção certa porque não haverá nenhuma referência à sua 
proposta original. Talvez eles não se lembrem das diferenças. No entanto, 
comparar as duas opções lado a lado, na mesma view, permite que todos 
vejam o que mudou e mostra claramente qual design resolve o problema. 


2. Propor uma alternativa 


A próxima tática para responder é oferecer uma solução alternativa que 
atenda à necessidade de um modo diferente. No Capítulo 3, investimos 
tempo para antecipar as reações de nossos stakeholders e, de modo 
preventivo, preparamos alternativas que poderiam ser usadas nessa 
situação. Agora é hora de trazer essas ideias à mesa para que fique claro que 
há mais de uma forma de solucionar o problema. Talvez você tivesse uma 
ideia semelhante na ocasião, tenha alguns designs que não chegaram à reta 
final, ou a sugestão dada por eles era parecida, mas não o suficiente. Você 
poderia propor algo totalmente diferente ou até mesmo sugerir uma solução 
intermediária. Qualquer que seja o caso, propor uma alternativa é uma 
necessidade em quase todas as situações. 


Ed 


E raro que os stakeholders estejam suficientemente em sintonia com o 
usuário e com o design da interface a ponto de serem proficientes para 
propor soluções que não exijam nenhum tipo de refinamento. Mesmo que as 
sugestões deles sejam realmente boas, não se esqueça de pensar nas 
implicações de forma crítica e agregue valor ao processo para deixá-lo 
ainda melhor. Isso não significa que devemos descartar a contribuição dos 
stakeholders como irrelevantes nem valorizar mais as nossas ideias do que 
as deles. Nosso trabalho é considerar seriamente essas sugestões e então 
aplicar nossa própria expertise para dar um passo além. Como especialistas 
em design, essa é a situação em que mais agregamos valor. 


Muitos stakeholders não conhecem o vocabulário para sugerir mudanças 
significativas em nosso trabalho de uma maneira que faça sentido para o 
usuário final. Com base em minha experiência, tenho constatado que, 
quando as pessoas utilizam termos genéricos para descrever uma solução, é 


sinal de que elas realmente não sabem qual é a melhor solução e as nossas 
alternativas são bem-vindas. Uma forma comum de isso se manifestar 
ocorre com o uso da palavra “botão”, apesar de um botão raramente ser a 
solução correta para um problema complexo de design. Em vez de 
acrescentar o botão, escolha um controle de UI mais apropriado, mova-o 
para uma posição diferente ou faça com que ele seja mais sutil. Há sempre 
uma forma mais apropriada de implementar as sugestões dos stakeholders 
do que apenas aceitá-las exatamente como foram dadas. 


Stakeholder: Basta colocar um grande botão no cabeçalho. 


Designer: Sim, entendo o que você quer dizer. Eu recomendaria utilizar um link 
textual em vez disso e adicionar um ícone para enfatizá-lo, em vez de usar um 
botão completo, que competiria com as demais opções no menu. Isso também seria 
consistente com os outros links utilitários que usamos em outros lugares. 
Com efeito, a maioria dos stakeholders espera que nossas próprias 
sugestões sejam trazidas à mesa e sejamos capazes de oferecer soluções aos 
problemas que eles identificarem. Na verdade, é por isso que eles nos 
pagam. Não tenha medo de represálias ao tomar o feedback que eles derem 
e aplicá-lo de uma maneira diferente. Mesmo que a opinião deles venha a 
prevalecer, você mostrará que seu processo de raciocínio foi deliberado e 
fará com que saibam que essas decisões não são tomadas sem serem 
consideradas. Um histórico que mostre que você é capaz de propor 
alternativas com elegância fará você conquistar o respeito de seus 
stakeholders como um parceiro confiável, que está sempre interessado em 
melhorar o produto deles o máximo possível. 


3. Dar uma opção aos stakeholders 


Uma terceira tática é dar aos stakeholders uma opção entre algo que você 
sabe que eles querem e a novidade que você está sugerindo. Você quer 
apresentar a sugestão que eles deram, junto com o que eles perderão se 
avançarem por esse caminho. Eles terão de fazer um sacrifício. Isso é muito 
eficaz caso o que eles forem perder seja mais importante do que aquilo que 
estão propondo. 


No comportamento dos clientes, o medo de perder é mais forte do que a 
promessa de ganho. E por isso que temos cupons que expiram, preços 
promocionais para quem comprar mais cedo e ofertas por tempo limitado. 


O medo de perder um bom negócio se sobrepõe ao nosso raciocínio lógico 
sobre a real necessidade de adquirir aquilo que está sendo anunciado. Sem 
que tentemos manipular nossos clientes para que tomem decisões 
precipitadas, podemos usar esse conhecimento em nosso favor e ajudar as 
pessoas a verem melhor as prioridades do design, tendo em vista a 
experiência completa do usuário. O que eles perderão se fizermos o que 
estão propondo? Tirar proveito dessa perda em potencial pode ser muito 
eficaz. 


Essa tática não tem o intuito de ser uma forma de assumir o controle, do 
modo como um pai poderia forçar uma decisão de seu filho à mesa do jantar 
dizendo: “Você não poderá comer a sobremesa a menos que coma suas 
verduras”. Em vez disso, é uma tentativa honesta de fazer com que os 
stakeholders estejam cientes das implicações da opção proposta por eles. É 
preciso que eles saibam que qualquer decisão afeta tudo o mais. Nosso 
trabalho é estar atento a essas conexões e informá-las caso sejam relevantes 
para a discussão. 


Muitas vezes, associo isso à resolução do Cubo Mágico porque alguém virá 
a nossa reunião e dirá: “Quero que essa face seja vermelha. Se você girar 
aqui, meu lado será vermelho”. Nosso trabalho é estar bem atento a essas 
conexões a ponto de podermos responder: “Sim, adoro vermelho! Também 
quero que esse lado seja vermelho, mas, se eu girar esse lado, isso afetará 
ou outros lados também, e eu preciso resolver o cubo como um todo”. 
Como muitas pessoas querem que suas ideias estejam em primeiro plano no 
design, muitas vezes é possível mostrar que a solução delas terá um efeito 
negativo na experiência, como um todo, do usuário. 


Eis alguns exemplos: 


a 


e “Se adicionarmos essa nova chamada à ação, o formulário de login será 
movido mais para baixo na página” Você sabe que eles pediram 
explicitamente que o formulário de login estivesse bem acima, e movê- 
lo poderia afetar as conversões de forma negativa. 


* “Adicionar aquilo exigirá um pouco de tempo, portanto, se fizermos isso, não 
conseguiremos lançar a versão com os gráficos no painel de controle” Você 
sabe que os gráficos no painel de controle são uma prioridade nessa fase 
e, por comparação, a sugestão do stakeholder não é tão importante. 


“Se colocarmos essa nova opção no menu, não haverá espaço suficiente para 
os itens existentes. Teremos de remover Preferences (Preferências) ou History 
(Histórico).” Você sabe que essas opções fazem parte do conjunto básico 
de recursos, enquanto as novas opções agregam menos valor ou até 
mesmo causam distrações na experiência do usuário. 


* “Mudar esse link textual para um botão o fará competir com os outros botões 
da página. Se fizermos isso, teremos de remover ou alterar os outros botões a 
fim de acomodá-lo” Você sabe que os outros botões foram 
deliberadamente projetados para atrair o máximo de atenção, e 
acrescentar outro deixará o visual muito mais carregado. 


* “Mover a mensagem para a coluna à direita significa que não poderemos 
oferecer produtos com várias opções. Devemos deixar de oferecer suporte 
para esses produtos?” Você sabe que devemos oferecer suporte para 
produtos com várias opções e, desse modo, mover a mensagem não é 
possível. 


“Adicionar um logo aqui distrairá o usuário das tarefas associadas a seus 
perfis. Se tivermos de adicionar o logo, eu recomendaria refatorar o design 
das tarefas de perfil do usuário para que sejam menores e mais sutis.” Você 
sabe que as tarefas de perfil do usuário são o ponto principal dessa view. 
e colocar um logo nessa área não agregará nenhum valor à experiência 
do usuário. 


Em cada caso, estamos enfatizando a relação de custo-benefício. Isso não só 
permite que os stakeholders vejam o feedback que deram levando em conta 
todas as demais prioridades do projeto, como também os envolve no 
processo de decisão, capacitando-os com as informações corretas. Sempre 
que você permitir que outra pessoa concorde com você de uma maneira que 
pareça ter sido a decisão dela, faça isso. Pense no que será perdido no 
processo, preste atenção em todas essas conexões e se manifeste se souber 
que haverá efeitos negativos na experiência do usuário. 


4. Pedir a outras pessoas que se manifestem 


A quarta tática é solicitar a ajuda de outras pessoas e pedir a elas que se 
manifestem na decisão. É nessa hora que o tempo e o esforço que você 
investiu para construir bons relacionamentos, criar uma rede de pessoas que 
o apoiem e pedir às pessoas que participem da reunião compensarão. Há 


outras pessoas na sala que concordarão com você, e você vai pedir a elas 
que se manifestem diretamente. Criar uma atmosfera de consenso em torno 
de seus designs dará força à sua argumentação e ajudará seus stakeholders a 
verem que há outros experts que concordam com você. Isso mostra aos seus 
stakeholders que há outras pessoas que concordam, eles só precisam se 
juntar a vocês. 


Também ajudará a defender seus argumentos sem que você se veja forçado 
a assumir a posição desconfortável de discordar abertamente de um 
stakeholder. Isso se deve, parcialmente, ao fato de você deixar que outras 
pessoas falem, tirando a pressão sobre você. Além disso, porém, se outras 
pessoas puderem concordar com você (em vez de discordar diretamente 
com um stakeholder), uma atmosfera positiva será mantida, em vez de 
haver uma acusação explícita de que uma pessoa está errada. Você desviará 
a atenção da divergência com um stakeholder, enfatizando que outras 
pessoas concordam com você. 


Ao pedir a outras pessoas que se manifestem na discussão, é importante se 
lembrar de sempre fazer o pedido diretamente e permanecer neutro: 


Peça diretamente 


Chame as pessoas pelo nome e pergunte diretamente o que elas acham. Se 
você pedir feedback para o grupo todo, algumas pessoas se manifestarão 
discordando da outra pessoa. Você deve pedir a um único indivíduo que 
dê a sua opinião. Por exemplo: “David, o que você acha disso?”, ou 
“David deu uma opinião interessante sobre isso agora há pouco. David, 
você poderia compartilhá-la conosco”. 


Permaneça neutro 

Não peça feedback de um modo que revele seus verdadeiros sentimentos 
sobre a sugestão do stakeholder. Em vez disso, faça perguntas abertas (que 
não sejam do tipo sim/não) usando termos como “opinião”, “ponto de 
vista” ou “perspectiva”. Peça às pessoas que falem o que acharam ou 
quais foram suas reações, de modo geral. Diga, por exemplo: “David, 
gostaria de ouvir qual é o seu ponto de vista sobre isso”, em vez de 
colocá-lo contra outra pessoa: “David, você concorda com Susan?”. 


No meio de duas equipes 


Em um de meus maiores clientes, duas equipes diferentes de UX estavam 
trabalhando juntas em um projeto especial pela primeira vez. Cada equipe 
tinha um ponto de vista diferente, e os dois grupos tinham opiniões fortes. 
Eu estava preso entre elas, tendo recebido a tarefa de gerenciar uma 
discussão sobre prioridades concorrentes. Quando chegamos a alguns 
detalhes da UI, como cores específicas e o posicionamento de pequenos 
detalhes, percebi que era muito mais difícil chegar a um consenso. O líder 
de uma das equipes falava mais e tinha opiniões mais fortes que as outras 
pessoas. Eu sabia que, se conseguisse o apoio dele, seria mais fácil tomar 
uma decisão. 


Decidi compartilhar meus designs com ele com antecedência e chegamos 
aquilo que achávamos ser a melhor solução. Quando chegou o momento de 
todos se reunirem, eu pedi, especificamente, a ele que compartilhasse o seu 
ponto de vista. Como tinha um cargo mais alto, além de ter mais habilidade 
para falar, ele defendeu meu design sem que eu tivesse de me envolver com 
os pequenos detalhes acerca dos quais havia claras divergências com as 
outras pessoas. Ele fez o trabalho árduo de defender meus designs, eu 
permaneci à margem da complexidade dos relacionamentos e mantivemos a 
experiência do usuário exatamente como queríamos que ela estivesse. Pedir 
a outras pessoas que se manifestem é uma ótima maneira de garantir que 
você conseguirá o apoio para proporcionar a melhor experiência possível 
aos usuários. 


5. Adiar a decisão 


Por fim, se todas as táticas anteriores fracassarem para fazer a discussão 
avançar em uma direção positiva, sugiro adiar a decisão. Antes de permitir 
que sua equipe tome qualquer decisão que terá impactos negativos na 
experiência do usuário, prefira esperar. Poderiam ser apenas algumas horas 
ou até mesmo alguns dias, o que for necessário para você dar um passo 
atrás, compreender o problema e voltar com uma solução melhor. Com 
muita frequência, decisões apressadas, que pareciam uma boa ideia no 
momento, acabam se mostrando ser escolhas ruins quando são 
implementadas. Qualquer pessoa apreciará o fato de você querer ter um 
tempo para fazer o que é certo e verificar se a solução sugerida é 
apropriada. Desse modo, peça para ter esse espaço. 


Você pode adiar a decisão começando com um sim, dizendo algo como: 
“Sim, entendo o que você quer dizer e nós realmente precisamos encontrar 
a solução correta. Que tal se eu trabalhasse nisso nas próximas horas e 
então poderemos entrar em contato novamente antes do fim do dia”. A 
ideia de que você está adiando a decisão não precisa deixar o seu progresso 
mais lento. De qualquer modo, iterar em seus designs é uma boa prática; 
portanto, esteja preparado para receber o feedback de seu stakeholder e sair 
correndo com ele, mesmo que seja durante uma reunião. Não ignore essa 
prática, fazendo com que você perca seu tempo. Em vez disso, aproveite o 
momento para tirar proveito de sua própria energia e promover o seu 
trabalho, fazendo acontecer nesse instante. 


Reunião adiada 


Certa vez, eu estava trabalhando em uma pequena equipe quando a sugestão 
de uma pessoa passou a ser um brainstorm, que se transformou em uma 
solução que estava muito distante do problema, a ponto de mal ser 
reconhecível. Essa é a minha opinião, é claro, mas, enquanto via a 
discussão se desenrolar, percebi que a conclusão inevitável era que a 
mentalidade de grupo que estava gerando essa solução Frankenstein 
acabaria se transformando em algo muito distante do ideal. Era hora de me 
manifestar e fazer algo a respeito! 


Interrompi a discussão dizendo que estava claro que precisávamos chegar a 
uma decisão e um design-por-comitê provavelmente não ajudaria. Em vez 
de desperdiçar o tempo de todos continuando com a discussão, cancelei a 
reunião naquele mesmo instante e mandei todos de volta para suas 
escrivaninhas, depois de decorridos apenas 15 minutos de uma reunião de 
uma hora. Enquanto isso, permaneci na sala de reuniões e criei rapidamente 
várias alternativas que seriam mais úteis para conduzir a reunião, sem que 
houvesse cinco pessoas olhando por sobre meus ombros e tocando na minha 


tela 2 


Antes de transcorrida aquela hora, chamei todos de volta para analisar as 
opções que eu havia acabado de criar. Uma delas parecia funcionar, foi 
ajustada e, posteriormente, conseguiu chegar ao ambiente de produção. O 
resultado foi um produto melhor porque eu havia parado a locomotiva 
maluca antes que ela saísse da estação. Adiar a decisão, mesmo durante 


alguns minutos, me deu o espaço necessário para que eu voltasse com uma 
solução que ajudaria a garantir a melhor experiência possível aos usuários, 
sem menosprezar as ideias que haviam sido lançadas na ocasião. Além 
disso, poupei a todos da perda de tempo e do transtorno de desperdiçar suas 
capacidades mentais, que somente teriam resultado em retrabalhos. 


Nem sempre será necessário cancelar suas reuniões dessa forma, mas a 
questão é que é melhor parar (mesmo por apenas alguns minutos) e fazer 
com que seus designs estejam corretos, em vez de deixar que uma única 
decisão ruim force você involuntariamente a uma UX que seja um beco sem 
saída. É mais provável que seja possível propor um adiamento da decisão 
até a manhã seguinte; com isso, você será capaz de descobrir uma solução 
melhor a tempo. Não seja apressado e jamais tenha medo de sugerir que a 
decisão seja adiada. 


Para ser um comunicador eficaz, você precisa aprender a responder às 
pessoas com muita rapidez na hora da reunião. A única maneira de ser bom 
nisso é praticando, memorizando a sua estratégia (as respostas para os três 
pontos essenciais) e aplicando essas táticas no momento da reunião. Essa 
resposta formará a base com a qual você e seus designs serão julgados; 
portanto, ela deve ser cuidadosamente formulada e passível de ser colocada 
em ação. Quanto mais você treinar, mais competente será. 


A boa notícia é que, além de ter uma estratégia bem definida e táticas 
facilmente aplicáveis, muitas discussões de design giram em torno de temas 
e ideias semelhantes. Você pode tirar proveito disso lembrando e 
reutilizando respostas parecidas e comuns em todas as ocasiões. No 
Capítulo 7, compartilharei algumas das mensagens básicas mais comuns, 
usadas para justificar as decisões de design, para que você tenha alguns 
modelos preparados para articular a sua resposta. 


1 Dale Carnegie, How to Win Friends and Influence People (New York: Simon e Schuster, 
1936). (N.T.: Edição publicada no Brasil: Como fazer amigos e influenciar pessoas). 


2 Não toque na minha tela! 
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Agora que estamos formulando nossa resposta aos stakeholders, vamos 
analisar rapidamente o que temos até o momento. Nosso objetivo é obter 
seu apoio. A estratégia para consegui-lo é informar que nosso design 
resolve um problema, facilita a vida dos usuários e é melhor que as 
alternativas. Comunicaremos isso utilizando qualquer uma das táticas que 
vimos no Capítulo 6. Então, precisamos agora identificar as mensagens que 


nos ajudarão a empregar aquelas táticas em nosso contexto. 


Embora todo projeto seja diferente e cada cliente tenha necessidades únicas, 
percebi que há algumas maneiras de explicar as decisões de design que eu 
utilizo de forma recorrente. Com frequência, dou os mesmos tipos de 
explicações para os meus projetos, e eu as compilei neste livro como 
referência. Algumas são parecidas ou se relacionam entre si, mas elas 
deverão dar a você uma boa base para os tipos de resposta que são eficazes 
nas discussões de design. 


Essas são as mensagens essenciais que você pode usar para implementar a 
sua estratégia e alcançar seu objetivo. Com a nossa estratégia e as táticas 
em mente, identifique as mensagens que mais se aplicam à sua situação e 
modifique-as a fim de adaptá-las ao seu contexto específico. O objetivo 
deste capítulo é apresentar a você uma lista das maneiras comuns de 
descrever as decisões de design, que podem ser usadas e reutilizadas em 
qualquer reunião. 


Eu as organizei em quatro categorias (em nenhuma ordem em particular): 
Negócios, Design, Pesquisa e Limitações. 


Negócios 


Uma das melhores maneiras de argumentar em favor de seus designs é 
associá-los diretamente às necessidades dos negócios. Eis as três respostas 
mais comuns para ser convincente quando se trata de negócios: 


* “Ajuda a alcançar um objetivo”; 
e “Facilita um caso de uso”: 
e “Comunica a marca”. 


“Ajuda a alcançar um objetivo” 


Os stakeholders sempre apreciam quando você associa a sua solução aos 
objetivos dos negócios. É uma maneira sólida de argumentar a favor de seu 
design, apelando para um motivo mais nobre. Essa pode muito bem ser a 
sua resposta à pergunta: “Qual é o problema que o nosso design resolve?” 
porque, em geral, os problemas que queremos resolver com o design são 
iguais aos objetivos gerais do projeto ou dos negócios. Qualquer que seja a 
base do raciocínio, sempre enfatize que o seu design tem o propósito de 
ajudar a empresa a atingir seus objetivos. 


Pode ser difícil saber ao certo como um design em particular afetará seus 
objetivos, sobretudo no caso de interações pequenas, que talvez não afetem 
o uso geral da aplicação como um todo. A questão, nesse caso, não é saber 
com certeza. Se sempre soubéssemos ao certo qual é a solução que, 
indubitavelmente, nos permitiria alcançar nossos objetivos, nem sequer 
precisaríamos da reunião. Tenha confiança e acredite que, dada a sua 
experiência, e até o ponto em que é possível ter certeza, esse design é, no 
mínimo, um dos passos de uma abordagem mais ampla que o levará até 
onde você precisa chegar. 


Para fazer isso de modo eficaz, deixe essa associação clara e explique como 
a sua solução resolve esse problema específico. Como você já registrou 
cada problema por escrito, junto com a respectiva solução (conforme 
recomendei no Capítulo 1), e parte de sua estratégia consiste em apelar para 
um motivo mais nobre, você será capaz de dar uma explicação que 
comunique claramente essas conexões. Um padrão para expressar isso é: “O 
[design] afetará o [objetivo] porque [motivo]”. Eis alguns exemplos: 


e “Colocar “Related Items” (Itens relacionados) antes da descrição do 
produto aumentará o engajamento porque os usuários terão mais 


oportunidades para ver outros produtos.” 


e “Colocar “Recent Projects” (Projetos recentes) no topo da tela inicial 
melhorará a qualidade dos dados porque os usuários terão um acesso 
mais fácil para manter seus dados atualizados.” 


* “Eliminar o requisito de login reduzirá a taxa de abandono porque os 
usuários poderão ignorar o cadastramento e, ainda assim, conseguirão 
ver as promoções, mesmo não estando logados.” 


Isso não quer dizer que todos concordarão. Afinal de contas, você poderia 
pensar que usar uma chave toggle para “Remember password” (Lembrar a 
senha) aumentaria o engajamento ao manter os usuários logados, mas eu 
poderia achar que uma caixa de seleção de uso testado e comprovado seria 
uma solução mais eficaz. O propósito não é esperar que todos concordem 
automaticamente. É mostrar que todas as nossas decisões são feitas de 
forma deliberada, com vistas a um propósito, e essa é uma maneira de 
comunicar isso aos nossos stakeholders. Associe suas decisões de design a 
metas e objetivos de negócios com a maior frequência possível. 


“Facilita um caso de uso” 


Essa talvez seja a explicação mais comum e óbvia para qualquer decisão de 
design, pois tudo que fazemos diz respeito a criar um design com base em 
um caso de uso, uma história de usuário ou um conjunto de funcionalidades 
específico. Nossos stakeholders talvez não saibam como usamos essas 
técnicas para criar uma estrutura e a lógica para as nossas decisões. Dar 
destaque aos casos de uso que se beneficiarão com a decisão é uma boa 
maneira de mostrar o seu processo de raciocínio, fazendo com que você fale 
da decisão de uma maneira que faça sentido aos stakeholders. 


Com a mesma frequência, tentamos fazer otimizações para um caso de uso 
principal, minimizando e limitando os casos de uso secundários ou raros. 
Por exemplo, embora todo usuário seja incentivado a manter suas 
informações no perfil de sua conta, esse não é o propósito principal da 
aplicação. Isso dá fundamento à nossa decisão de colocar as funções de 
gerenciamento de conta em um menu suspenso, em vez de usar uma 
chamada à ação proeminente. Enfatizar essas justificativas pode ajudar você 


a fazer com que as pessoas permaneçam concentradas em garantir que o 


caso de uso principal seja sempre otimizado, mesmo diante de outras 
necessidades e funcionalidades. 


Ainda que fazer o design para um caso de uso possa parecer Óbvio, é 
surpreendente a frequência com que, em um ambiente de grupo, as equipes 
podem tomar decisões que ignorem totalmente o uso principal da aplicação. 
Como você já estabeleceu que suas decisões estão associadas a esse caso de 
uso, lembre-se de fazer uma verificação rápida e confirmar que não o tenha 
perdido de vista no processo de mover os itens de lugar. Mesmo após uma 
decisão ter sido tomada, é sempre bom voltar e verificar novamente as suas 
decisões com base nos casos de uso documentados, para os quais você 
espera que o design seja feito. Se perceber que sua equipe está se perdendo, 
traga-a de volta para o caminho certo, lembrando a todos quais são os casos 
de uso relevantes e como suas decisões os afetarão. 


“Comunica a marca” 


Com frequência, eu me vejo justificando as decisões de design com base 
exclusivamente nos padrões de comunicação da marca da empresa. Às 
vezes, os designs são como são porque a empresa tem uma imagem 
específica que busca consolidar, e nossas aplicações também devem refletir 
essa postura. Isso vale mais para o uso de cores, de fontes ou da linguagem 
em vez de interações específicas, mas é importante destacar esse aspecto. Se 
você escolheu determinado estilo porque é o que as diretrizes para a marca 
definem, chame a atenção dos stakeholders para esse fato. 


Às vezes, o design da aplicação pode ser uma boa oportunidade para 
trabalhar com uma empresa e ajudá-la a comunicar a identidade de sua 
marca. Mesmo que, em geral, essa não seja uma parte explícita do processo 
de UX, algumas empresas não têm padrões que incluam estilos para 
elementos como botões, listas suspensas e caixas de seleção. Como 
resultado, talvez tenhamos a chance de ajudá-las a melhorar a 
documentação de seus padrões com o nosso próprio guia de estilos e dar 
uma direção positiva à identidade visual da empresa. Os profissionais de 
marketing, muitas vezes, não pensam nos controles da interface. Os padrões 
que eles criam visam, basicamente, a atender às suas próprias necessidades, 
por exemplo, o uso em publicidade ou materiais impressos. Ajudá-los a 
entender os pontos em que nos deparamos com desafios para implementar 


esses padrões em nossa interface pode dar forma a uma discussão para 
incluir outros elementos que sejam importantes para a UX. No fim, o 
resultado será uma melhor colaboração entre as áreas e um manual mais 
abrangente para a gestão da marca. Isso também deixará os stakeholders 
satisfeitos. 


Design 


Muitas vezes, temos motivos relacionados ao design para explicar por que 
fizemos o que fizemos. Percebi que há três maneiras comuns de descrever 
minhas decisões por razões ligadas ao design: 


* “Utiliza um padrão comum”; 
* “Chama a atenção do usuário”; 
e “Cria um fluxo para o usuário”. 


“Utiliza um padrão comum” 


Muitas empresas utilizam sistemas comuns de design, bibliotecas de 
padrões ou guias de estilo que facilitem encontrar um padrão existente para 
resolver um problema de negócios. O ideal é que esses padrões ou 
componentes já estejam implementados, testados e tenham um histórico de 
uso. 


Além disso, os designers, muitas vezes, usam seu tempo vendo outros sites, 
aplicativos e dispositivos, conhecendo os padrões de design mais recentes e 
convenientes; desse modo, escolhem, naturalmente, padrões que façam 
mais sentido para o público-alvo e o contexto. Escolher um padrão pode ser 
arriscado se não entendermos por completo o contexto para o qual ele foi 
originalmente projetado; no entanto, escolher um padrão de forma 
deliberada porque ele é amplamente conhecido pode ser uma ótima maneira 
de argumentar a favor de suas decisões. 


Seus stakeholders talvez não tenham conhecimento do conceito de 
“padrões” no design de UI; portanto, você deve ter cuidado para não fazer 
com que eles se sintam deslocados. Ajude seus stakeholders a entender que, 
como essa consistência na experiência do usuário é muito importante, 
alterar um padrão esperado em um contexto terá como efeito cascata a 


necessidade de utilizar o mesmo padrão em outros locais da aplicação. Essa 


não é apenas uma decisão isolada. Usar um padrão é conveniente para os 
nossos usuários; além disso, para a empresa, em geral, também será mais 
fácil e mais barato para desenvolvê-lo. 


Lembre-se, porém, de que os padrões de design foram criados para oferecer 
consistência e definir as expectativas dos usuários quanto às interações que 
irão ocorrer. Exceto por isso, será infrutífero argumentar acerca de qual 
padrão funcionará sem uma pesquisa sólida para sugerir o contrário. 


“Chama a atenção do usuário” 


Há partes de nosso trabalho de design que são mais orientadas pela intuição 
do que outras, e essa é uma daquelas explicações genéricas que parecem 
justificar muitas de minhas próprias decisões que, de outro modo, eu não 
conseguiria comunicar. Há muita psicologia envolvida quando pensamos na 
direção em que os usuários vão olhar, como eles passam os olhos (sem ler) 
pela tela e o que faz com que eles se movam de um ponto para outro. Boa 
parte desse conhecimento é expresso na prática de design por meio de 
técnicas, como uso de cores, espaço negativo, equilíbrio ou tamanho da 
fonte. Essas ideias podem ser extremamente subjetivas e difíceis de 
justificar para uma pessoa comum, mas, em geral, é fácil explicar que a 
combinação de elementos que ela vê na tela tem como propósito fazer o 
usuário se mover do ponto A para o ponto B. 


Eis alguns exemplos: 

* “O título e a chamada para a ação estão organizados de modo que o 
usuário leia primeiro o título e depois dê um toque na chamada à ação.” 

e “Os contêineres se sobrepõem para dar aos usuários a sensação de que 
estão conectados quando eles fizerem rolagens pela página.” 

* “Os elementos estão organizados da esquerda para a direita e de cima 
para baixo porque o nosso público-alvo tende a passar os olhos pela 
página dessa forma.” 


* “Usamos verde porque verde quer dizer siga em frente ou sucesso, e o 
contraste atrairá os olhos do usuário para esse elemento.” 


E importante ajudar nossos stakeholders a entender o relacionamento entre 
os elementos de design e a ação do usuário para que eles possam perceber o 
raciocínio por trás de nossas decisões. Devemos informar que não estamos 


apenas colocando os elementos na página de uma maneira que pareça 
bonita, mas estamos tentando atrair os usuários para a aplicação e levá-los a 
agir por meio de um posicionamento apropriado dos elementos de design. 
Nossas decisões se baseiam em fazer o usuário agir; em última instância, 
esse é o propósito de qualquer site ou aplicação. 


“Cria um fluxo para o usuário” 


Muito tempo e esforço são dedicados à criação de fluxos para o usuário. 
Podemos passar dias ou semanas com uma parede cheia de notinhas 
adesivas, tentando descobrir qual é o melhor caminho para os nossos 
usuários navegarem pela aplicação. Essa hierarquia é expressa em nosso 
trabalho e influencia o modo como estruturamos todo o design. Definimos 
casos de uso, casos raros e fluxos de erro, além de remover os becos sem 
saída, somente para ouvir um stakeholder sugerir uma mudança que 
desestruturará todo esse fluxo, podendo nos enviar de volta à prancheta de 
desenho. Ocasionalmente, nem chegamos a perceber isso: fazemos uma 
mudança em um lugar, e essa mudança afeta outro ponto mais adiante. Sem 
querer, arruinamos o caminho que procuramos planejar com tanto cuidado, 
com base nos caprichos de um stakeholder bem-intencionado, porém, 
desinformado. Preste muita atenção em como suas decisões afetarão o fluxo 
que você criou. Não deixe que seus stakeholders o arruínem, sem antes 
entender por que você criou o fluxo dessa maneira. 


e “Nosso fluxo de checkout foi desenhado para que cada controle 
sucessivo para o próximo passo esteja exatamente no mesmo lugar, e o 
usuário avance de forma linear. Se fizermos a mudança que você está 
propondo, o fluxo será interrompido no passo 3, fazendo com que o 
usuário tenha de parar e voltar, em vez de concluir rapidamente o passo 
e avançar.” 


* “Nosso fluxo para cadastramento exige que apenas o endereço de email 
seja submetido antes porque poderemos reduzir a taxa de abandono se 
não expusermos todos os campos de uma só vez, permitindo que o 
usuário adicione depois as informações em seu perfil, de forma gradual. 
Se incluirmos os campos adicionais nesse passo, as regras de validação 
complicarão o processo, e o fluxo do usuário será interrompido caso um 
erro tenha de ser corrigido antes.” 


Pesquisa 


Usar dados, testes com usuários e outras pesquisas talvez seja a justificativa 
mais convincente para as nossas decisões de design. Tenho três respostas 
comuns que são convenientes quando usamos pesquisas para dar 
sustentação às nossas decisões: 


* “Validado por meio de dados”; 
* “Revelado nos testes”; 
* “Apoiado por outra pesquisa”. 


“Validado por meio de dados” 


Usar dados para defender suas decisões de design é um modo certeiro de 
obter o apoio dos stakeholders porque é a maneira mais científica de 
demonstrar que seus designs têm o efeito desejado. A importância de usar 
dados não pode ser subestimada. Com frequência, as empresas têm muitos 
dados para ajudá-las, mas não têm tempo nem aptidão para explorá-los e 
extrair conclusões significativas; assim, encontre dados que sejam úteis para 
o seu contexto e permita que esses dados ajudem você em sua 
argumentação. 


Às vezes, os designers têm dificuldade para entender uma planilha cheia de 
porcentagens e decimais — e eu me incluo nesse grupo. Espero que haja 
alguém que possa ajudar você a ver um sentido nos números, ou talvez seja 
possível ter acesso a um conjunto de slides no qual os dados estejam 
apresentados em um formato mais palatável. Em geral, os donos de produto 
e os gerentes de projeto são as pessoas que ajudarão você nesse trabalho, 
mas é bem provável que você mesmo tenha de fazer o trabalho de analisar o 
caos e estabelecer conexões entre os elementos de seu design e o 
comportamento do usuário. Não é fácil, mas a boa notícia é que esse 
esforço compensa bastante, pois quase todo mundo se convence com dados. 


Há dois tipos de dados que podemos usar quando falamos de nossas 
decisões. O primeiro tipo são os dados existentes, isto é, dados que já estão 
disponíveis e podem ser usados para nos ajudar a tomar uma decisão 
imediata. O segundo são os dados refletidos, ou seja, dados que coletamos 
depois de ter alterado o nosso design, permitindo comparar o antes e o 
depois. Com o primeiro tipo, podemos dar palpites bem fundamentados. 


Não sabemos realmente se a solução proposta por nós ajudará a atingir o 
objetivo, mas podemos utilizar os dados para dar o nosso melhor palpite. O 
segundo é obtido depois do palpite: testamos nossas alterações e 
verificamos se os números são melhores. Quando temos esse tipo de 
informação, vemos mais claramente qual é a resposta “correta”. 


Usar dados realmente facilita convencer os stakeholders. Por esse motivo, 
também é importante reconhecer que ter dados ruins levará à escolha 
errada; portanto, precisamos ser realmente cuidadosos com essa abordagem. 
O que eu quero dizer é que os dados, muitas vezes, nos dizem o que o 
usuário fez, mas não por quê. Tentamos inferir o porquê observando o quê, e 
isso, naturalmente, envolve fazer suposições. Se fizermos mudanças com 
base em uma suposição incorreta, acabaremos com um design que, em vez 
de resolver os problemas, provavelmente causará outros. Portanto, tenha em 
mente que tomar decisões com base em dados poderá ser realmente eficaz 
somente se esses forem considerados no âmbito do projeto como um todo, 


no contexto apropriado, sem muitas pressuposições. 


Uma de minhas ex-gerentes era uma pessoa orientada a dados. Eu e ela 
podíamos discutir diferentes designs por horas, mas, se dados para apoiar 
um dos lados entrassem no cenário, era um caso decidido e encerrado. 
Percebi isso rapidamente e descobri que, sempre que eu reunia dados para 
defender a minha proposta, ela concordava. Era estranho ter esse poder, 
pois se tornou tentador exagerar os números a fim de defender meus 
argumentos, mesmo que não houvesse conexões realmente diretas. Esse é o 
problema com os dados: quase todos são convencidos por eles, mas os 
dados podem ser facilmente manipulados. O ponto a ser lembrado, nesse 
caso, é que o nosso objetivo não é simplesmente conseguir que os 
stakeholders concordem, e faremos os designs do jeito que quisermos. 
Nosso objetivo é proporcionar a melhor experiência possível aos usuários e 
ajudar nossos stakeholders a atingir suas metas. Distorcer uma perspectiva 
com base em dados para defender nossos argumentos de modo egoísta não 
se mostrará eficaz no longo prazo. 


Para chamar a atenção de seus stakeholders, é importante iniciar a resposta 
com uma frase que enfatize o seu uso dos dados, por exemplo: 


e “De acordo com a nossa análise de dados...”; 


* “Temos dados que sugerem que...” 
e “Estamos monitorando essa métrica e...”. 


Em geral, bastará apenas declarar, de modo confiante, o que os dados 
mostram, sem a necessidade de mais discussões: 


e “De acordo com a nossa análise de dados, 64% dos usuários desistem 
nesse ponto do fluxo de usuário.” 


e “Temos dados que sugerem que o requisito de número de telefone é 
nossa principal barreira para a conversão.” 


e “Estamos monitorando essa métrica e vimos uma queda acentuada no 
engajamento desde que fizemos essa alteração ” 


No entanto, esteja sempre preparado para apresentar os dados que citar, 
mesmo que não os tenha à mão. Em geral, guardo os dados em um arquivo 
separado ou em um relatório que tenha visto antes, e sei que posso 
compartilhá-los com os stakeholders se eles pedirem. Quase sempre, será 
suficiente dizer a eles que o relatório poderá ser enviado mais tarde, quando 
você fizer o acompanhamento posterior (follow up). Contudo, apresentar os 
dados visualmente, de forma simples, na própria reunião, para que os 
stakeholders possam realmente se convencer da ideia, é uma boa prática. 
Como muitas pessoas são visuais, exibir um gráfico, uma imagem ou uma 
tabela simples contribui para que elas entendam a importância dos dados 
nessa decisão em particular. 


Tráfego 


Acesso ao carrinho 
de compras 


Início do checkout 


Desistência de 83% 


Pedidos concluídos 


Ter recursos visuais disponíveis para mostrar os dados é um modo muito eficaz de defender seus 
argumentos. 


Você deve decidir quais são os tipos de dados mais relevantes para seus 
stakeholders e otimizar seus designs de modo a melhorar as métricas em 
questão. Usar dados para apoiar suas decisões é muito convincente, desde 
que você estabeleça uma conexão profunda com esses dados e faça as 
suposições corretas. 


“Revelado nos testes” 


Muitas vezes, passamos pela experiência de observar as pessoas usarem 
nossos designs, e esses insights dão sustentação à nossa tomada de decisões. 
Saber, de forma consciente, quando esses estudos influenciam nossas 
decisões ajudará em nossa comunicação com os stakeholders, nas ocasiões 
em que for apropriado. Exibir um bom design, conectando-o com um 
estudo de usabilidade, é um modo muito eficaz de defender seus designs 
porque mostra que suas ideias funcionam com pessoas reais. Há aí um 
elemento humano, que cria uma narrativa para os nossos stakeholders, em 
vez de termos a simples frieza dos dados brutos. Dependendo de seus 
stakeholders, usar histórias reais de usuários pode ser até mesmo mais 
eficaz do que utilizar números e gráficos. Empregando a tática do Capítulo 
6 de representar o usuário, conte aos stakeholders uma história sobre os 
usuários que os faça concordar com a sua decisão. 


O desafio com a observação de usuários como justificativa para as decisões 
de design é que ela pode ser muito subjetiva, tendo como base o que você 
se recorda da sessão, e é difícil documentar essas observações para que 
sejam levadas a uma reunião com um cliente. Em geral, levamos esses 
dados aos nossos stakeholders na forma de uma memória, algum 
conhecimento especial que pode estar somente em nossas mentes, por 
exemplo: “Durante o nosso estudo de usabilidade na semana passada, 
percebemos que as pessoas estavam confundindo os botões “OK” e 
“Cancelar” porque o design era muito parecido”. Ainda que essa afirmação 
tenha como base a nossa experiência com os usuários, não há dúvidas de 
que ela está turvada pela nossa própria memória e as conclusões a que 
chegamos com o estudo. Apesar disso, é um modo eficaz de demonstrar que 
você está interagindo com os usuários e aperfeiçoando seus designs de 


/ . 


modo a incluir o que aprendeu. Esse já é, por si só, um ponto muito 
importante a ser comunicado. 


A melhor maneira de comunicar os insights que obtivemos das sessões de 
testes com usuários é criar um conjunto de slides com citações de alguns 
usuários selecionados e talvez incluir até mesmo um videoclipe mostrando 
as áreas com problemas. Edite o vídeo da sessão, reduzindo-o a alguns 
segundos, ou crie um vídeo com a seleção das partes mais relevantes do 
estudo. Isso mostra que você valoriza o tempo de todos mostrando somente 
as partes importantes, ao mesmo tempo que dá às pessoas a oportunidade de 
participar de uma verdadeira sessão de usuário. Embora isso exija uma 
preparação prévia, é a única forma de realmente mostrar aos seus 
stakeholders o motivo pelo qual você fez o que fez, e a necessidade poderá 
ser maior dependendo do escopo das mudanças propostas. Eu recomendaria 
mostrar inclusive uma ou duas sessões de usuário completas, se houver 
tempo disponível. Percebo que, muitas vezes, essa é a primeira vez que 
meus stakeholders veem uma sessão de usuário! Sempre que puder fazer 
com que seus stakeholders vejam seu aplicativo sendo usado por pessoas 
reais, você criará uma conexão que permite que eles tenham empatia e se 
sintam motivados a agir de modo a promover mudanças em favor desses 
usuários. 


Criando uma ficha 


"Acho difícil inserir o 
histórico do paciente 
nesse ponto porque, em 
geral, não tenho essas 
informações à mão 
Preciso voltar depois e 
corrigi-las, e, às vezes, eu 


me esqueço 


Incluir um videoclipe curto ou uma citação de uma sessão de usuário em seus slides é um modo 
eficaz de dar aos seus stakeholders um acesso rápido a usuários reais. 


“Apoiado por outra pesquisa” 


Para mim, na hora de discutir o design, é comum citar outras pesquisas 
(muitas vezes externas) que eu tenha visto. Passo bastante tempo lendo 
blogs, livros e consumindo podcasts. Além disso, ocasionalmente, tenho 
acesso a fontes de dados de terceiros, ou até mesmo a analistas de dados 
internos. Muitas vezes, essas informações influenciam meu raciocínio de 
um modo que chega a ser quase inconsciente. Descubro práticas boas e 
novas o tempo todo, e começo a incorporá-las em meu trabalho sem nem 
mesmo me dar conta do fato. Em geral, nem percebo que isso aconteceu até 
conversar com os stakeholders e analisar o meu processo de decisão 
naquele instante. Eu me pego dizendo algo como: “Li recentemente que...” 
e, então, preciso voltar para encontrar essas fontes de dados originais. 


Como resultado, adquiri o hábito de salvar as pesquisas úteis em uma pasta 
do projeto ou manter uma lista em um documento compartilhado, para que 
eu possa disponibilizá-las facilmente para outras pessoas. À medida que 
navego casualmente por outras pesquisas, copio links, citações e dados em 
um arquivo separado, que seja possível consultar depois, se for necessário. 
Em geral, minhas anotações incluem o título, o autor, o URL e uma 
descrição da parte que é relevante para o meu projeto ou um breve resumo 
das descobertas. Isso me facilita bastante para argumentar com base em 
outras pesquisas porque posso rapidamente enviar o material de consulta 
para o meu cliente, se ele pedir. 


Na verdade, é muito raro ter de apresentar a pesquisa original como prova, a 
menos, é claro, que as pessoas discordem de você. Na maioria das vezes, os 
stakeholders aceitam esse tipo de declaração conforme foi dada e confiam 
em você quanto ao resto. De modo muito parecido com a análise de dados, 
esse pode ser um tipo perigoso de poder porque, se você tem a tendência de 
exagerar ou não se lembrar corretamente dos dados, as decisões que tomar 
ainda poderão ser ruins. Por esse motivo, não recomendo citar outro estudo 
se você não tiver a referência à disposição. Às vezes, o que você lembra 
sobre um estudo e o aprendizado propriamente dito é bastante influenciado 
pelo seu próprio ponto de vista. 


Em outras ocasiões, porém, ter todo o material para referência é essencial 
para justificar suas decisões. Quando o que está em jogo é muito 


importante, essa talvez seja a única maneira de convencer as pessoas de que 
o seu design é a melhor opção. Contudo, a situação poderia ser injusta se 
seus stakeholders não estiverem preparados para defender as próprias 
opiniões diante de sua lista de pesquisas previamente preparada. Se você 
não tomar cuidado, pode parecer um ataque. Nesse caso, dê aos 
stakeholders uma oportunidade para pensar no assunto e responder em outra 
ocasião, envie sua pesquisa com antecedência para que eles tenham a 
chance de analisá-la, ou leve uma pesquisa que apresente os dois lados do 
problema para a discussão. Você não vai querer que os stakeholders se 
sintam em uma emboscada. 


Tirando o hambúrguer do menu 


Ah, o delicioso ícone do menu hambúrguer. 


Um dos projetos de aplicativos móveis no qual trabalhei utilizava o “menu 
hambúrguer”, muito comum, para a navegação principal. Durante um 
processo de revisão do design, tentei várias vezes (sem sucesso) convencer 
meu cliente a abandonar o uso desse ícone como um guarda-chuva para 
tudo no menu. Minha recomendação tinha como base uma pesquisa que 
mostrava que o ícone não era tão eficaz quanto a palavra “Menu”, mas 
apenas dizer isso ao cliente não bastava para convencê-lo. Em uma reunião, 
juntei o máximo possível de artigos sobre o assunto (alguns dos quais 
discordavam de minha posição) e os abri em abas diferentes do navegador 
para defender meus argumentos. Quando alcançamos esse item da agenda, 
apresentei o design que eu estava propondo (novamente) e, em seguida, 
cliquei cuidadosamente em cada uma das abas para apresentar um resumo 
rápido de cada artigo. Quando terminei, os representantes do cliente 
estavam impressionados com minha preparação; eles admitiram que não 
possuíam um volume semelhante de evidências para dar suporte à opinião 


deles, e reiniciamos a discussão sobre mudar o ícone. Como resultado, 
decidimos fazer um teste A/B com as duas opções propostas, na esperança 
de que teríamos uma base melhor para a nossa tomada de decisão. Se eu 
não tivesse me preparado com essas pesquisas, não teria sido possível 
reiniciar essa discussão. 


Ao usar outras pesquisas externas para dar apoio às suas decisões, lembre- 
se do seguinte: 
e Desenvolva o hábito de salvar as pesquisas em um documento separado 
à medida que encontrá-las. 
e Anote o título, o autor, o URL/fonte e a data. 


e Escreva um breve resumo da postagem ou uma frase sobre como ela se 
relaciona com o seu projeto. 


* Forneça uma lista de referências aos seus stakeholders quando for 
solicitado. 


* Encontre pesquisas que defendam outros pontos de vista para que haja 
um equilíbrio na compreensão. 


e Dê aos seus stakeholders uma chance de considerar a pesquisa ou 
responder com uma pesquisa que eles mesmos tenham encontrado. 


Limitações 

Do mesmo modo que, com frequência, justificamos nossas decisões com 
base naquilo que achamos que precisa ser feito, também argumentamos 
quando há limitações que devam ser levadas em consideração. Nem sempre 
podemos fazer o que nossos clientes querem, simplesmente por causa de 
outros fatores que estão além do nosso controle ou porque tentamos seguir 
padrões de design e de programação. Tenho três respostas comuns para lidar 
com as limitações: 


e “Não há recursos suficientes”; 
* “Limitado pela tecnologia”; 
* “Obedece a um padrão”. 


“Não há recursos suficientes” 


A triste realidade do design é que, muitas vezes, as empresas não têm tudo 


de que precisam para realizar seus sonhos para o seu aplicativo ou site. 
Simplesmente não há dinheiro ou pessoas suficientes para que todos possam 
fazer o design e criar tudo aquilo que puderem imaginar. Levar essas 
limitações em consideração é uma parte importante do processo de tomada 
de decisões porque gastar tempo de mais com algo que não seja possível 
não seria um uso eficiente do tempo. Embora, em geral, as limitações para 
os recursos sejam apenas uma questão de dinheiro e de pessoas, há quatro 
áreas principais que parecem afetar o design de sites e de aplicativos, mais 
do que outras áreas: 


Suporte 

Não há suporte, infraestrutura ou processos internos para lidar com os 
requisitos adicionais. Mesmo que possamos desenvolver e lançar o nosso 
projeto, não haverá suporte interno suficiente para mantê-lo no longo 
prazo. Isso poderia ocorrer porque o serviço de assistência ao cliente não 
está organizado para lidar com as chamadas adicionais, a área de 
contabilidade não tem prática suficiente para lidar com os pagamentos ou 
a área de QA (Quality Assurance, ou Controle de Qualidade) não tem 
capacidade para testar outro aplicativo. Não é tanto uma questão de 
pessoas, mas de processos. A empresa simplesmente ainda não está 
preparada para lidar com o que queremos fazer. Essas estruturas de 
suporte são um ponto importante a ser considerado quando fazemos o 
design, e levá-las em consideração em nosso processo de decisão é uma 
questão relevante, que deve estar bem clara. 


Pessoas 


Não há designers nem desenvolvedores suficientes que possam realmente 
criar o design no prazo dado, com as restrições existentes. Falando de 
modo simples, aquilo que queremos fazer exige uma equipe maior, que 
não está à nossa disposição. Talvez nem seja um problema de orçamento, 
mas de contratação: não conseguimos contratar os tipos apropriados de 
talentos ou não somos capazes de contratar com a rapidez necessária. 
Talvez seja apenas um problema de curto prazo, mas não ter pessoas 


suficientes é um motivo legítimo ao avaliar nossos designs. Sempre 
considere como seus designs serão afetados pela equipe atual e no futuro. 


Dinheiro 
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O orçamento é insuficiente para adquirir a tecnologia ou os serviços 
necessários para concretizar o projeto. Não importa o dinheiro que você 
tenha, ele será quase sempre insuficiente. Há sempre outro hardware ou 
um novo serviço incrível que pode ser usado para expandir o nosso 
produto e levá-lo para o próximo patamar. Contudo, na falta desses 
recursos, devemos restringir nossos designs para que levem em conta um 
limite no orçamento. Deixar esse motivo explícito em suas decisões de 
design é importante. 


Tempo 

Não há tempo suficiente para implementar os designs, considerando os 
requisitos atuais. E, quando o tempo é limitado, em geral, limitamos 
nossas ideias até chegarem a um ponto que sejam factíveis. O mais 
importante é comunicar esse “downgrade” percebido. Qualquer 
stakeholder deseja criar o maior e melhor aplicativo o mais rápido 
possível, é por isso que muitas equipes começam com um produto mínimo 
viável e fazem iterações com o tempo. Teoricamente, não deveríamos 
jamais ser forçados a dizer a um stakeholder que não há tempo suficiente 
porque o nosso processo é concebido de tal forma que sempre criamos 
níveis apropriados de trabalho para cada ciclo. Na verdade, estamos 
sempre limitando as ideias para que se enquadrem no cronograma atual. 


Dizer aos seus stakeholders que você está limitado por causa de recursos 
resultará em uma concordância solene ou em profunda indignação. 
Qualquer que seja o caso, o resultado poderá ser bom. Por um lado, os 
stakeholders poderão concordar com você porque entendem a realidade da 
situação no que diz respeito aos recursos. Por outro, poderão se sentir 
impelidos a trabalhar por você a fim de conseguir recursos adicionais e 
fazer o projeto acontecer. Entretanto, a questão não é realmente o resultado, 
mas a sua capacidade de explicar racionalmente a realidade e as restrições 
com as quais você está trabalhando. Devemos sempre fazer o design 
considerando nossas limitações quanto aos recursos. 


“Limitado pela tecnologia” 


Embora gostaríamos de pensar que nós, designers, somos capazes de criar 
qualquer coisa, a verdade é que estamos limitados pela tecnologia. O que 
tivermos à nossa disposição naturalmente nos forçará a tomar decisões de 


design que devem ser explicadas aos nossos stakeholders. Muitas vezes, 
essas limitações não podem ser previstas quando criamos os designs 
originais, e é somente durante a implementação que teremos de fazer esses 
ajustes. Nossos stakeholders tinham determinadas expectativas, mas, na 
hora de o projeto se concretizar, percebemos que temos de fazer alguns 
sacrifícios. 


Às vezes, essas limitações são evidentes e, simplesmente, não há meios de 
acomodar as requisições feitas pelos stakeholders. Um exemplo comum no 
design para aplicativos móveis é o tamanho da tela do dispositivo: 
simplesmente não há espaço para tudo. Em outras ocasiões, haverá 
limitações mais estritamente técnicas. Por exemplo, eu estava trabalhando 
em um aplicativo web para dispositivos móveis, e o cliente queria acessar a 
câmera do dispositivo no navegador. Embora isso seja tecnicamente 
possível, o suporte para esse recurso não está amplamente disseminado, e 
remover essa opção do escopo foi uma decisão fácil. Também poderia ser o 
caso de haver outros fatores tecnológicos que estejam além de seu controle 
e forcem suas decisões. Talvez o servidor simplesmente não seja capaz de 
fazer o que você precisa ou a tecnologia que você quer não está disponível 
com facilidade e a um custo baixo. Nesses casos, é apropriado sugerir que, 
embora todos concordem que a ideia seja ótima, não é possível considerar a 
implementação desses designs, a menos que haja uma tecnologia melhor. 


Nem sempre é fácil. Essas talvez sejam as decisões mais difíceis que você 
terá de ajudar as pessoas que não são designers (nem desenvolvedores) a 
entender, pois os motivos, muitas vezes, são extremamente técnicos. Os 
stakeholders não gostam dessas limitações (ou não as entendem) e podem 
até mesmo ficar irritados com a perspectiva de que você não possa fazer o 
mesmo que os concorrentes fazem. Imagino um executivo puxando seu 
celular, mostrando o modo como outra empresa faz e perguntando a você: 
“Por que não podemos fazer isso?”. Contudo, essas limitações são reais, e 
precisamos ajudar nossos stakeholders a enxergar as limitações para que 
eles possam participar da decisão. 


“Obedece a um padrão” 


Ocasionalmente, o que os nossos stakeholders querem que façamos estará 
em desacordo com os padrões técnicos ou sociais que definimos para a 


nossa aplicação. Queremos que nossa aplicação funcione em todos os 
navegadores, em diferentes dispositivos e para todas as pessoas; portanto, 
temos de seguir as “regras” que foram definidas antes, do lado do 
desenvolvimento. Às vezes, isso resulta em alterações em nosso design para 
que possamos nos ajustar a esses padrões. 


Um exemplo é o design para acessibilidade. Quando estiver desenvolvendo 
uma aplicação com acessibilidade, isso servirá de base para as decisões 
sobre os tipos de controle escolhidos e como as interações serão 
implementadas no design. Em geral, começamos com um design sem 
restrições; assim que a implementação estiver em andamento, ele será 
reduzido para o que é realmente possível, considerando o nosso desejo de 
fazer com que a aplicação funcione para todos. Embora quase tudo seja 
tecnicamente possível, nem sempre a solução será recomendável (ou pode 
demorar muito para ser implementada); desse modo, devemos ajustar 
nossas expectativas de modo a levar em consideração essas necessidades. 


Outro exemplo comum envolve os tipos de controle padrão do HTML. 
Talvez o stakeholder queira um selecionador de data personalizado, mas a 
perspectiva de desenvolver e manter seu próprio selecionador está fora do 
escopo. Nem sempre “fazer por conta própria” será a decisão correta; 
portanto, é melhor explicar por que usar um controle padrão é mais 
conveniente, tanto para o usuário como para o objetivo geral da empresa. 
Às vezes, elementos da página com alto nível de interação exigem hacks de 
programação para serem implementados. Nesse caso, você talvez tenha de 
se afastar de uma solução excessivamente complicada se o objetivo for criar 
uma aplicação que funcione em diferentes dispositivos ou navegadores. Em 
cada caso, estamos tentando mostrar que os padrões definidos para as 
aplicações têm uma vantagem natural para o nosso processo de 
desenvolvimento, assim como para a portabilidade e a acessibilidade da 
aplicação no longo prazo. Esses padrões servem de base para as nossas 
decisões de design e as influenciam. 


Web versus nativo 


Eu estava dando consultoria para uma organização sem fins lucrativos a respeito 
de um aplicativo web móvel. Embora o aplicativo executasse em todos os 
principais navegadores para dispositivos móveis, o cliente queria que ele se 
comportasse mais como uma aplicação nativa. Para isso, a equipe deles havia feito 


um design de uma série de interações e de padrões de design que, embora fossem 
naturais para alguns aplicativos móveis nativos, teriam exigido que 
sobrescrevêssemos algumas funcionalidades nativas do navegador e, 
possivelmente, infringíssemos alguns padrões da web no processo. Isso não só 


EN 


apresentava desafios técnicos quanto à implementação, mas também criava um 
conjunto de interações confusas. Por exemplo, os usuários dos navegadores não 
conseguiriam fazer rolagens para cima e para baixo (scroll-jacking, isto é, 
sequestro de rolagem), e poderiam navegar pelo site apenas deslizando para a 
esquerda ou para a direita. No fim, consegui convencer o cliente que valorizar o 
comportamento nativo do navegador era mais importante do que manter a 
percepção de uma aplicação nativa. Na primeira implementação, ao menos, eles 
optaram por deixar de lado todos os eventos gestuais personalizados e se ativeram 
à solução HTML e JavaScript, testada e comprovada (baseada em padrões). 
Espero que agora você consiga ver como as decisões de design em 
diferentes projetos, muitas vezes, compartilham um raciocínio e uma 
explicação semelhantes. Como designers e comunicadores, nossos trabalhos 
são facilitados quando podemos recorrer a essa pequena lista de mensagens 
comuns, usando-as como base para a nossa resposta. Utilize-as como 
modelos para ajudar você a dar início à sua resposta, independentemente do 
contexto. 


Mantendo o foco em nosso objetivo de obter o apoio dos stakeholders, 
temos agora uma estratégia memorizada, um conjunto de táticas que podem 
ser colocadas em prática e uma lista de mensagens frequentemente usadas 
como base para a nossa resposta. O próximo passo é reunir e inserir tudo 
isso em uma fórmula que, finalmente, nos fará alcançar o nosso objetivo. 
Estamos somente a um passo de cumprir a nossa promessa de articular 
(explicar) as decisões de design de modo eficaz, de uma maneira que seja 
convincente e incentive todos a concordarem. A seguir, vamos formular 
uma resposta ideal. 
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Chegue a um acordo 


À reunião 
Fazer o 


Entender Ouvir Responder follow-up 


vo SEO 


Já discutimos várias táticas para formular sua resposta, bem como algumas 
das maneiras mais comuns de responder a um feedback sobre o design. Ao 
combinar todas essas práticas, podemos ver de que modo elas formarão a 
base para uma resposta padrão aos stakeholders, determinando uma fórmula 
para o sucesso. 


Qualquer resposta a um feedback de design deve englobar uma série de 
áreas para ter o tipo de relevância necessária, de modo que seja satisfatória 
e convincente. Em discussões sobre UX, tenho uma fórmula útil para ajudar 
você a argumentar junto aos stakeholders. É a Resposta IDEAL: 


Identifique o problema 


Devemos sempre manter o foco e garantir que nossos stakeholders 
estejam cientes do problema que estamos resolvendo; caso contrário, a 
discussão poderá rapidamente se tornar contraproducente. De forma bem 
concisa, descreva o problema que o seu design resolve para que todos 
estejam na mesma sintonia. 


Descreva a solução 


É nesse ponto que o seu design específico pode ser associado ao problema 
que você está tentando resolver. Estabeleça uma conexão clara entre o que 
você fez e como isso resolve o problema. Se a solução não estiver clara, o 
design será inútil e ineficaz. 


Estimule a empatia com o usuário 


Os stakeholders podem se esquecer das pessoas do outro lado de nossos 
produtos. Nosso trabalho é representá-las; é sentir que somos tão 
responsáveis por elas a ponto de sermos levados à ação. Explique como a 
sua solução resolve o problema de um usuário específico, chamando a 


atenção para quem são as pessoas que estão em primeiro plano no seu 
processo de design. 


Afirme a importância da solução para os negócios 

Não basta apenas fazer correções. Todas as nossas decisões devem ser 
motivadas, em parte, por uma necessidade de fazer os negócios ou a 
empresa crescerem. É nesse ponto que você descreve como suas decisões 
foram tomadas com o intuito de afetar os objetivos, as métricas ou os 
KPIs (Key Performance Indicators, ou Indicadores Básicos de 
Desempenho). Mencione-os, faça a conexão deles com o seu trabalho e 
demonstre a sua importância. 


Leve a um acordo 


Depois de argumentar com clareza, peça diretamente que os stakeholders 
concordem com você. Você não deve deixar essa conversa em aberto, sem 
uma definição. Faça uma pergunta direta aos stakeholders: “Você 
concorda?”. Coloque-os em uma posição em que tenham de responder a 
você e faça com que o projeto avance. 


Da IDEIA ao IDEAL 


Fazer com que todos concordem em seguir adiante, sem dúvida, é o 
propósito deste livro. Sem essa concordância, tudo que você conversar com 
seus stakeholders não passará de uma IDEIA. Você pode fazer uma ótima 
apresentação, comunicar a sua posição e sair da reunião se sentindo 
confiante, mas, sem o apoio de todos da equipe, seu projeto não será bem- 
sucedido. É por isso que chegar a um acordo é tão importante, pois permite 
que você avance, partindo de algo que seja apenas uma ideia para 
transformá-la em algo realmente IDEAL. 


Ao longo do livro, traçamos uma linha divisória entre obter o apoio 
necessário e ter a concordância de todos quanto à solução. Você jamais terá a 
concordância de todos quanto a uma solução específica, mas poderá obter o 
apoio de todos, fazendo com que concordem em seguir adiante com a solução 
proposta por você. O fato de concordarem com os detalhes não é tão 
importante quanto o fato de concordarem em prosseguir com a solução. 


Seja direto 


Para chegar a um acordo, você deve pedir diretamente a adesão de seus 
stakeholders. O modo mais simples é perguntar: “Você concorda?”. 
Coloque-os em uma posição em que precisem dar uma resposta para você, 
antes de prosseguirem com a reunião. Além disso, deve estar claro que você 
está pedindo uma resposta específica (uma concordância) e que espera deles 
um posicionamento. 


É fácil que uma discussão de design acabe resvalando casualmente para um 
punhado de ideias aleatórias, até que, em algum momento, as pessoas 
sintam que a discussão deve continuar. No entanto, se ainda não houve um 
acordo, não deixe que a equipe passe para o próximo item da agenda. Você 
deve ser o responsável por interromper a conversa o suficiente para dizer: 
“Antes de dar prosseguimento, estamos todos de acordo em seguir adiante 
com essa proposta?”. Obter essa confirmação verbal é importante para 
garantir que esse item não surja novamente na próxima reunião porque 
alguém se esqueceu do que foi decidido. 


Enfatize as vantagens e os riscos 


Além dechegar a um:vantagens e consequências” ser direto, formule sua 
pergunta de modo que seus stakeholders queiram dar a resposta de que você 
precisa. Em outras palavras, deixe claro qual é a opção que você acredita 
ser a correta pela maneira que fizer a pergunta, para que eles sejam 
impelidos a responder que concordam. Isso pode ser feito enfatizando o 
efeito negativo se discordarem, ou as vantagens ao concordarem. Por 
exemplo: “Você concorda que devemos melhorar a conversão removendo 
esses campos?”. Nesse caso, você está enfatizando e lembrando os 
stakeholders de que a sua solução tem o intuito de melhorar a conversão. 


Force uma resposta clara 


Por fim, perguntar diretamente aos seus stakeholders se eles concordam 
também os forçará a ser diretos na resposta. Às vezes, os stakeholders não 
mostram claramente as suas reações, e precisamos que eles nos digam 
exatamente o que acham para que possamos atingir o nosso objetivo. Se 
eles discordarem, precisamos saber, e não deve haver nenhuma dúvida a 
esse respeito. Ao formular sua pergunta de forma direta e enfatizar o efeito 
que a solução terá na experiência do usuário, os stakeholders serão 


impelidos a dar uma resposta que deixe a posição deles muito clara. Se não 
se sentirem seguros, eles poderão concordar com você somente para que a 
reunião prossiga. Caso contrário, você terá uma oportunidade para 
continuar a discussão e chegar à solução apropriada a fim de atender às 
necessidades de todos. Qualquer que seja o caso, você terá uma resposta 
definitiva. 


Juntando tudo 


Começaremos agora a aplicar tudo que discutimos até então, formulando 
uma resposta coerente que: 


* ofereça uma transição natural usando a abordagem Agradeça, Repita, 
Prepare; 


* considere nossas respostas aos Três Pontos Essenciais; 


e aplique quantas táticas forem necessárias para defender nossos 
argumentos; 


e tire proveito de respostas comuns às considerações sobre o design; 


* encapsule tudo na Resposta IDEAL a fim de obter a concordância e o 
apoio dos stakeholders para seguir em frente. 


Apresentaremos a seguir vários estudos de caso. São exemplos de como 
responder ao feedback de um stakeholder usando a Resposta IDEAL. 
Minha intenção é apresentar algumas situações comuns e suas respostas 
para mostrar como é possível apresentar as decisões de design de forma 
articulada aos seus stakeholders. Posso ou não ter vivenciado essas 
situações pessoalmente com meus clientes. Não posso confirmar nem negar 
a existência desses cenários na vida real! Os nomes dos padrões de projeto e 
dos controles de UI foram modificados para proteger a privacidade das 
pessoas. 


Para simplificar, evitei fornecer muito contexto sobre o produto ou a 
discussão. Estes exemplos são suficientemente comuns, a ponto de ser 
possível inferir o bastante somente com base em seus contextos. Em cada 
caso, não mantenha o foco nos detalhes específicos do feedback; em vez 
disso, considere a maneira de comunicar o que é importante para os 
stakeholders, de uma forma que seja relevante para as suas necessidades. 


Do 


Controle sobre o meu conteúdo 


Agradeça, | Obrigado por me apresentar sua ideia de poder ordenar manualmente o conteúdo de 

repita, sua página. Sei que você gostaria de ter um pouco mais de controle sobre o modo 

prepare como suas postagens são exibidas, e estamos limitando propositalmente o nível de 
controle dado aos criadores de conteúdo para ajudar a manter certo nível de 
consistência; portanto, vamos conversar sobre a melhor maneira de ajudar você. 


Identifique | Nosso desafio é que se supõe que toda view esteja em ordem cronológica, de modo 

o problema | que os usuários saibam que podem esperar ver o conteúdo mais recente no início. Isso 
mantém a lista de postagens atualizada e garante que todos os criadores de conteúdo 
submetam conteúdos novos toda semana. 


Defina a Em vez de dar a você a capacidade de ordenar todo o conteúdo manualmente, eu 

solução sugeriria adicionar um recurso por meio do qual você possa “fixar” (pin) um artigo no 
início de seu stream a qualquer momento. Se você fixar um novo artigo, ele 
substituirá o artigo existente. Adicionaremos um ícone especial ou uma pista visual 
para mostrar que o artigo está fixado. 


Estimule a | Com isso, o usuário continuará entendendo que nossos streams de conteúdo estão em 
empatia ordem cronológica. As pistas visuais os ajudarão a entender que esse único item 

com o fixado foi removido do stream de conteúdo habitual. 

usuário 


Afirme a Para você, essa postagem única estará em destaque entre todas as demais, 
importância | possibilitando que ela tenha uma exposição extra por mais tempo. Além disso, você 
da solução | terá um senso maior de controle sobre como as informações são exibidas, sem correr 
para os o risco de que todos comecem a reordenar seus conteúdos. 

negócios 


Leve a um | Você acha que selecionar um artigo especial de cada vez é uma solução aceitável? Ou 
acordo ainda acha que seria melhor permitir que todos ordenassem seus próprios conteúdos? 


Interação “Adicionar no carrinho” 


Agradeça, | “Obrigado por compartilhar suas ideias conosco acerca desse projeto. Seus insights 
repita, são realmente valiosos e agradeço por você ter revisado tudo isso conosco. Vou 
prepare retomar cada um dos pontos que você levantou para que possamos discuti-los. 
Algumas de nossas decisões têm base em uma explicação com a qual eu acho que 
você concordará quando começarmos a falar dela. 
Inicialmente, gostaria de analisar a nova interação de “Adicionar no carrinho”. 


Identifique |O problema que estamos tentando resolver é o fato de os usuários ficarem confusos 
o problema | com a presença de dois botões quando veem essa interface pela primeira vez e não 
saberem realmente o que cada um deles significa, ou em qual botão devem tocar. 


Defina a Nossa solução foi consolidá-los em um único botão chamado “Adicionar no 

solução carrinho”. Tocar no botão único mostrará mais opções e permitirá ao usuário fazer 
uma segunda escolha após ter confirmado a primeira, em vez de ter de tomar todas 
essas decisões antes. 


Estimule a | Tenha em mente que nossos usuários, frequentemente, fazem pedidos em seus locais 
empatia de trabalho. Poderia ser um gerente ocupado andando pelo corredor e que perceba que 


com o uma lâmpada está queimada e precisa solicitar uma nova naquele instante. Não 
usuário contamos, necessariamente, com toda a atenção dele, e precisamos lhe apresentar 
opções que sejam realmente simples, que não exijam pensar muito. 


Afirme a Acreditamos que nossa solução aumentará a conversão porque, apesar de exigir um 

importância | toque extra do usuário, ela faz com que a opção de adicionar um item em seu carrinho 

da solução | seja muito mais simples. Não haverá nenhuma dúvida sobre o que “Adicionar no 

para os carrinho” significa porque isso está relacionado ao comércio eletrônico padrão. 

negócios Falando de modo simples, haverá mais pessoas tocando no botão “Adicionar no 
carrinho”. 


Leve aum |Sei que a empresa prefere a linguagem existente, mas acreditamos que essa nova 

acordo abordagem deve ser usada no ambiente de produção na próxima versão. Poderíamos 
até mesmo considerar um teste A/B com essa solução e a implementação atual para 
que possamos comparar diretamente os resultados. Gostaríamos de ver a conversão 
aumentar drasticamente este ano, e essa é uma das maneiras mais importantes de fazer 
isso acontecer. Você concorda? 


Excesso no uso da marca 


Agradeça, | Obrigado por suas contribuições sobre o logo e as cores. Concordo com você que 

repita, poderíamos fazer ajustes para melhorar a solução. O desafio é que o departamento de 

prepare marketing está conduzindo esse trabalho e tivemos pouca influência nas decisões 
finais. No entanto, acho que há alguns pontos a serem discutidos nesse caso. 


Identifique | A área de marketing gostaria de atribuir uma marca para essa iniciativa, de modo 

o problema | separado do resto do produto, a fim de criar uma campanha para ela e divulgá-la. O 
problema é que, em minha opinião, nossos usuários não entenderão a diferença entre 
essas submarcas. Eles usam a aplicação pela sua utilidade, e não pela marca dos seus 
add-ons, e colocar esses elementos extras, como logos e slogans, atrapalha. 


Defina a Minha sugestão é evitar o uso de um logo nesse espaço e, em vez disso, manter o foco 

solução do trabalho de gestão da marca no uso de cores e na cópia do texto para comunicar a 
mensagem. Nessa view em particular, poderíamos trabalhar com ícones pequenos 
para identificar os serviços add-ons ou adicionar uma linha da cópia com uma cor 
diferente para destacar a sua importância. Isso permitirá economizar uma área 
significativa do espaço com um mínimo de impacto para o usuário. Para isso, temos 
de voltar a falar com o pessoal de marketing e trabalhar com eles nessa solução. 


Estimule a | Do ponto de vista dos usuários, uma submarca como essa é irrelevante. Eles estão 

empatia interessados principalmente em executar suas tarefas e fazer o que tem de ser feito. 

com o Ao colocar um logo no caminho, criaremos um obstáculo à capacidade do usuário de 

usuário utilizar a aplicação de modo eficiente e, dessa forma, seu trabalho será mais lento. 
Isso será não só possivelmente frustrante para os usuários, como também colocará em 
risco a conversão para os serviços pagos, pois os usuários não conseguirão entrar no 
fluxo de modo tão rápido quanto poderiam. 


Excesso no uso da marca 


Afirme a Nosso objetivo para essa iniciativa foi criar outra oportunidade de receita para 

importância | serviços add-ons quando o usuário entrar no fluxo. Embora eu saiba que a área de 

da solução | marketing quer aproveitar essa oportunidade para criar outro produto com esses add- 

para os ons, acredito que uma abordagem que tenha uma marca não agregará valor aos 

negócios usuários (no melhor caso) e os confundirá, além de os atrasar (no pior caso). Em 
outras palavras, isso poderá, na verdade, atrapalhar nossos esforços para gerar receita 
com esse canal. 


Leve aum | Gostaria de sua ajuda para trabalhar com a área de marketing a fim de eliminar parte 

acordo dos requisitos relacionados à gestão de marca. Ficarei feliz em orientá-los acerca de 
algumas alternativas e ajudá-los a entender o ponto de vista do usuário. Você 
concorda que devemos fazer o nosso melhor para reduzir o uso de uma marca 
específica nos serviços add-ons? 


Confusão no menu principal 


Agradeça, | Obrigado por suas contribuições. Eu realmente agradeço o seu ponto de vista acerca 

repita, dessas mudanças e compreendo a sua sugestão quanto à necessidade de adicionar 

prepare essas novas opções no menu principal. No entanto, acho que há uma solução melhor, 
que podemos discutir para garantir que essas opções tenham visibilidade. 


Identifique |O problema que vejo é que, com frequência, adicionamos novas opções no menu 

o problema | principal, e ele está se transformando em um guarda-chuva para todo tipo de links 
quando não sabemos o que fazer com eles. Além disso, essas promoções não são 
ofertas permanentes, mas por tempo limitado; portanto, é improvável que um usuário 
as procure explicitamente no menu, pois eles não as veem como um conjunto 
permanente de opções. 


Defina a Minha sugestão é manter o foco de nosso trabalho em dar destaque a essas promoções 

solução nas áreas de conteúdo que já usamos para outras mensagens importantes, como alertas 
do sistema ou o texto de sugestão para pesquisa. Quando essas novas ofertas 
estiverem disponíveis, poderemos exibi-las nessas áreas de conteúdo e ter mais espaço 
ainda para imagens e outros conteúdos. 


Estimule a | Não queremos que nossos usuários fiquem sobrecarregados com o número de opções 
empatia no menu principal. Em vez disso, podemos agregar mais valor a eles adicionando 
com o mensagens apropriadas segundo o contexto, que sejam relevantes para a sua tarefa 
usuário atual. 


Afirme a Se colocarmos esses itens no menu principal, o tiro poderia sair pela culatra porque 
importância | será menos provável que as pessoas os achem nesse menu. Todavia, colocá-los 

da solução | estrategicamente nas áreas existentes da página poderia, na verdade, melhorar a 
para os visibilidade das ofertas e aumentar o engajamento para essa iniciativa. 

negócios 


Leve aum |Gostaria de seguir adiante com a ideia de utilizar nossas áreas existentes e fazer o 

acordo mockup de alguns exemplos para a nossa próxima reunião. Você concorda que isso 
dará mais visibilidade, além de melhorar a experiência do usuário? Ou você acha que 
seria melhor adicionar os itens no menu e correr o risco de ficarem perdidos no meio 
das outras opções? 


Banners com marca 


Agradeça, | Obrigado pela sua sugestão de adicionar o logo no cabeçalho do aplicativo. Sei que 
repita, você quer a marca presente na experiência do usuário e concordo que isso seja 
prepare importante; portanto, vamos conversar sobre a melhor maneira de fazê-lo. 


Identifique |O desafio em uma aplicação como essa é que há um espaço limitado para o usuário ter 
o problema | acesso a tudo na navegação. Além do mais, queremos que eles permaneçam 
concentrados em suas tarefas com o mínimo possível de distrações. 


Defina a O motivo pelo qual optamos por não incluir o logo no cabeçalho se deve ao fato de 

solução ele não oferecer nenhuma funcionalidade ao usuário. Ao deixar de incluí-lo, teremos 
mais espaço para as opções de navegação e uma interface mais simples para o 
usuário. 


Estimule a |O logo não agregará diretamente nenhum valor aos usuários depois que eles estiverem 

empatia na aplicação. Apenas serviria para reforçar a marca de um serviço que eles já estão 

com o consumindo. O usuário poderá manter mais facilmente o foco no uso eficiente da 

usuário aplicação porque terá uma distração visual a menos. Quanto mais itens pudermos 
remover da interface, melhor será a experiência do usuário. 


Afirme a A gestão da marca é importante, e é por isso que trabalhamos com a marca em nossas 

importância | cores, na linguagem e nas interações em toda a aplicação. Também disponibilizamos 

da solução | uma página “Sobre” que contém o logo, além de links para os outros produtos. Além 

para os disso, vale a pena destacar que os usuários já investiram em nossa marca, pois se 

negócios cadastraram para o serviço. A view de login também exibe o logo de forma 
proeminente. 


Leve aum |O site de marketing é, realmente, o melhor local para divulgar a marca com um logo, 

acordo enquanto a aplicação propriamente dita é o melhor lugar para manter o usuário 
concentrado nas tarefas. Gostaria de propor que mantivéssemos o usuário concentrado 
em usar nossa aplicação enquanto estiver logado, porém permitíssemos um uso mais 
explícito da marca em outros lugares em que seja mais relevante. Você concorda? 


Inserção do número de telefone 


Agradeça, | Obrigado pelo seu tempo e por compartilhar suas ideias conosco sobre esse novo 
repita, design. Você fez várias sugestões de mudanças, as quais eu anotei, e gostaria de 
prepare repassá-las uma a uma para que possamos ter certeza de que concordamos. 


Identifique |O primeiro ponto que você mencionou foi a necessidade de adicionar um campo para 

o problema | o número de telefone no formulário de cadastro. Nosso foco com esse trabalho é 
aumentar as conversões no formulário; portanto, nosso design foi otimizado visando a 
esse objetivo. 


Inserção do número de telefone 


Defina a Removemos o campo do número de telefone por alguns motivos. Em primeiro lugar, 

solução entrar em contato com os clientes usando o mesmo meio pelo qual eles entraram em 
contato com você é uma boa prática. Assim, uma submissão de formulário online 
implica um email, em vez de uma chamada telefônica. Em seguida, de modo geral, 
menos campos em qualquer formulário aumenta a conversão porque os usuários 
podem completá-lo com mais rapidez e não precisam pensar tanto no que estão 
inserindo. Por fim, tenho algumas pesquisas que mostram que basta a presença de um 
campo de número de telefone em um formulário para prejudicar a conversão em mais 
de 30%, mesmo que o campo não seja obrigatório. 


Estimule a | Isso se deve ao fato de muitos usuários se sentirem receosos de compartilhar seu 

empatia número de telefone, temendo que ele seja adicionado em uma lista de chamadas de 

com o telemarketing. Além disso, basta apenas a presença do campo do número de telefone 

usuário para que os usuários se mostrem desconfiados da empresa que o está solicitando. 
Muitos se perguntam: “Por que alguém iria precisar do meu número de telefone em 
um formulário online?”. 


Afirme a Sei que você gostaria de ter o número de telefone do usuário em seus registros, mas, 

importância | no que diz respeito ao nosso objetivo de aumentar a conversão, será melhor removê-lo 

da solução | do formulário. Depois da conversão, teremos muitas oportunidades para manter 

para os contato com o usuário, engajá-lo em um relacionamento e, aos poucos, adicionar 

negócios informações em seu perfil. Isso criará relacionamentos mais relevantes com os novos 
clientes e estabelecerá laços de confiança desde o princípio. Remover esse campo 
proporciona um melhor equilíbrio entre promover uma ótima experiência ao usuário e 
atingir nossos objetivos de negócios. 


Leve a um | Você concorda que não devemos incluir esse campo no formulário? Ou você acha que 
acordo vale a pena correr o risco de ter uma conversão menor? 


Excesso de mensagens 


Agradeça, | Obrigado pelo seu tempo hoje. Agradeço a sua colaboração em nosso projeto. Você 

repita, tem um ponto de vista único sobre os negócios, e eu gostaria de discutir algumas de 

prepare suas preocupações, bem como apresentar algumas de minha parte. Acho que 
concordamos quanto aos pontos nos quais devemos manter o foco. 


Identifique |O problema que estamos tentando resolver com esse design é informar o valor 

o problema | economizado pelo consumidor. Nossa abordagem tem como foco enfatizar o valor que 
as pessoas podem economizar com esses itens, sem que elas tenham que pensar 
muito. O desafio com a implementação atual é que a empresa definiu muitas 
mensagens para informar essas economias, todas em um espaço muito pequeno. 
Temos aí o preço normal, a porcentagem economizada, o valor economizado em 
dinheiro, frete grátis e um sinal de “Oferta especial”. Além disso, também fomos 
incumbidos de incluir mensagens relacionadas à urgência usando um timer, a 
quantidade disponível e a mensagem de “Oferta por tempo limitado”. 


Excesso de mensagens 


Defina a Nossa solução consiste em aplicar uma lógica e algumas regras quanto às mensagens 

solução que serão exibidas, e quando serão, para que o usuário não fique sobrecarregado com 
um excesso de mensagens de uma só vez. Por exemplo, devemos sempre escolher 
entre mostrar a porcentagem ou o desconto em dinheiro, mas nunca os dois valores. 
Nesse caso, mostramos a porcentagem economizada porque é maior do que 30% e 
expressa melhor o valor, mais do que o desconto em dinheiro, que é de apenas 3 
dólares. Em seguida, mostraremos o timer somente se o valor estiver para expirar em 
24 horas, e exibiremos a quantidade disponível somente quando certo limiar for 
atingido. Estruturar nossas mensagens com base nessa lógica é a melhor maneira de 
informar o valor ao consumidor, sem exibir uma confusão de mensagens, todas de 
uma só vez. 


Estimule a | Os consumidores não têm tempo para ler todos os detalhes, fazer as contas e descobrir 

empatia quais itens representam as melhores ofertas. Mostrar mensagens de mais somente 

com o causará mais confusão porque eles não saberão em qual mensagem deverão manter o 

usuário foco. Nossa abordagem permite ter algum controle sobre quais mensagens serão 
apresentadas para que possamos aliviar a carga dos consumidores, permitindo que se 
concentrem na compra do item. Isso resultará em decisões mais rápidas para a 
compra. 


Afirme a Se mantivermos o foco somente nas mensagens mais importantes e relevantes para 
importância | cada item, é mais provável que aumentemos as vendas e o faturamento com esses 
da solução |itens porque será mais fácil para os consumidores lerem e comprarem. Reduzir o 
para os número de mensagens que o usuário vê os deixa livres para decidirem comprar com 
negócios mais rapidez, resultando em uma melhor conversão. 


Leve a um | Ter uma proposta com um foco preciso, sem incluir tantas mensagens diferentes, é a 
acordo solução. Você concorda que devemos manter o foco de nossas mensagens a fim de 
simplificar a exibição dos valores para os nossos consumidores? 


Personalizar relatórios 


Agradeça, | Obrigado pelo seu ponto de vista sobre a view de lista de casos. Você deu ótimos 
repita, feedbacks e eu gostaria de repassar todos os pontos a fim de garantir que estamos de 
prepare acordo quanto ao que precisa ser feito. 


Identifique | Você mencionou que gostaria de ser capaz de personalizar cada relatório diretamente 
o problema |na view do próprio gráfico. Concordo que esse seria um ótimo acréscimo para a 
aplicação. 


Defina a Deixamos essa ideia de lado propositalmente porque ela não estava em nosso escopo 
solução para essa fase do projeto. O conceito exige o acréscimo de várias funcionalidades e 
um esforço de design para que a implementação seja realmente boa. 


Estimule a | Compreendemos que, embora essa funcionalidade pudesse ser conveniente para 
empatia alguns usuários, a maioria das pessoas que utiliza a aplicação não precisa desse nível 
com o de personalização. Por enquanto, a interface será mais simples sem ela. 

usuário 


Afirme a Se mantivermos o foco em terminar a view de casos em seu formato mais simples, 


importância 
da solução 
para os 
negócios 


Leve a um 
acordo 


conforme proposto, conseguiremos concluir esse conjunto de funcionalidades básicas 
dentro do cronograma e disponibilizar essa view para os usuários com mais rapidez. 
Depois disso, poderemos obter feedbacks adicionais dos usuários e criar um plano 
para implementar a sua ideia. 


Você se sente confortável em prosseguirmos sem essa funcionalidade por enquanto? 
Ou prefere que as prioridades de nossas tarefas sejam revistas e os cronogramas sejam 
ajustados a fim de acomodar essa funcionalidade? 


Quero um novo WIDGET 
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Obrigado por suas impressões sobre o painel de controle. Sim, concordo que um novo 
widget que mostre os totais gerais seria útil. Isso não estava nos designs originais; 
portanto, vamos discutir a melhor solução. 


O problema é que os gráficos precisam ocupar a largura completa da aplicação porque 
temos menos controle sobre a exibição, considerando que é uma solução de terceiros. 
Além disso, já estamos incluindo widgets para o status atual, assim como para os 
follow-ups, de modo que, simplesmente, não há muito espaço disponível para 
acrescentar outro. A organização atual dos widgets foi projetada para otimizar a 
aplicação e reduzir follow-ups posteriores. 


Eu recomendaria substituir o widget Current (Atual) ou o widget Follow-up por um 
novo widget Totals (Totais), se essa for a prioridade agora. Podemos usar as áreas 
existentes para o novo widget sem modificar o design e manteremos a interface mais 
simples, sem o acréscimo de outro item. 


O desafio com essa abordagem é que já analisamos as necessidades junto aos nossos 
usuários internos e eles concordaram que os nossos widgets atuais eram os mais 
necessários nessa primeira versão. Não gostaria de acrescentar mais um e criar 
desordem ou sobrecarregar os usuários com informações. Ao mesmo tempo, gostaria 
de satisfazer o requisito sobre o que eles expressaram ser os itens que precisavam ter 
nesse painel de controle. Sei que Hannah espera treinar sua equipe com base em 
nossos designs atuais. 


Para ser prático, mesmo trocar um widget por outro deixará o nosso progresso mais 
lento porque não temos um design para o novo widget e será necessário um novo 
suporte dos desenvolvedores. Do nosso ponto de vista, o lançamento da versão 
poderia atrasar em uma semana. Talvez mais. Ainda que o widget Totals seja 
interessante, ele não nos ajudará a alcançar o nosso objetivo de reduzir follow-ups 
posteriores. Se removermos um dos widgets existentes em favor do widget Totals, eu 
sugeriria modificar também os nossos objetivos, pois precisaremos de um novo alvo 
no qual manter o foco, com uma organização diferente dos widgets. 


Você gostaria de adicionar esse widget Totals, substituindo um dos outros? Em caso 
afirmativo, posso ajustar o nosso cronograma, levar essa mudança de volta para os 
usuários e, então, devemos discutir quais são nossos novos objetivos para essa fase. 


Os usuários nos disseram 


Os usuários nos disseram 
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Obrigado pelo seu tempo hoje e por compartilhar conosco o seu feedback sobre esses 
novos designs. Anotei tudo o que você sugeriu e gostaria de repassar cada um dos 
pontos para ter certeza de que entendemos. Em todos os nossos designs, estamos 
levando em consideração as necessidades tanto da empresa como dos usuários. Acho 
que, se você entender o nosso processo de raciocínio em algumas dessas áreas, isso 
ajudará na discussão. 


Sua primeira sugestão foi que mudássemos os campos de entrada no formulário de 
histórico médico. Essa é uma parte interessante da aplicação porque tem a maior taxa 
de abandono quando comparada com outras partes dela. Aproximadamente 40% dos 
usuários desistem antes de concluir essa seção. Gostaríamos de ajudar os usuários a 
concluir esse passo para que possamos garantir que cheguem aos passos subsequentes 
e alcancem o fim do processo. 


Nossa solução foi baseada em um pressuposto de que os nomes dos campos eram 
confusos para uma pessoa comum; portanto, nossa primeira tarefa foi atualizar os 
nomes usando uma linguagem mais conveniente para o usuário. A seguir, porém, 
conversamos com alguns funcionários do call center, que nos ajudaram a entender que 
muitos usuários simplesmente não têm os detalhes de seu histórico médico com eles 
naquele momento; portanto, exigir todos esses campos antes de prosseguir os força a 
abandonar o site. 


Para facilitar a vida de nossos usuários, removemos propositalmente vários dos 
campos obrigatórios, permitindo que eles indicassem quais informações tinham e 
quais seriam fornecidas mais tarde. Isso permite que eles concluam esse passo por 
ora, mesmo que seus dados estejam incompletos. Podemos pedir que eles completem 
esses dados na próxima vez que fizerem login ou podemos enviar uma notificação por 
email depois de alguns dias. O usuário terá um maior senso de controle e é mais 
provável que chegará ao próximo passo em virtude dessas mudanças. 


Para nós, isso significa que veremos taxas significativamente mais altas de submissão 
porque mais pessoas conseguirão chegar ao próximo passo. Além disso, teremos 
dados mais precisos porque alguns usuários estavam preenchendo informações falsas 
apenas para poderem prosseguir. Contudo, o bônus é o fato de que veremos menos 
chamadas ao serviço de assistência ao cliente porque os usuários agora conseguirão 
preencher os dados na aplicação sem precisar de ajuda. Isso nos proporcionará 
verdadeiras economias com o call center. Já estamos armazenando os dados conforme 
são inseridos; portanto, podemos retornar e completar os perfis dos usuários quando 
eles estiverem no local, se for necessário. Não há riscos de perder informações. 


Gostaríamos de ver um grande aumento no número de clientes que sejam capazes de 
preencher os dados em seus perfis, e acredito que essa é a melhor maneira de alcançar 
esse objetivo. Você concorda que essa solução ajudará a fazer isso? 


Usar uma fórmula para responder aos stakeholders pode parecer um modo 
forçado de criar uma conversa que deveria ser natural. O propósito da 
Resposta IDEAL é fornecer um modelo e uma estrutura que nos lembrem 
de mencionar todas as partes importantes em nossa resposta. A finalidade 


não é forçar você a empregar um determinado modo de falar que acabe 
parecendo mecânico ou rigoroso demais para ser considerado uma fala 
normal. Acho que manter o acróstico IDEAL na mente é uma forma fácil de 
me lembrar dela e garantir que incluirei tudo o que é preciso mencionar. O 
fato de você sempre formular sua resposta exatamente da mesma maneira é 
menos importante do que garantir que mencionou tudo o que era necessário. 
Lembre-se de que a questão principal é responder aos stakeholders de um 
modo que seja relevante às necessidades deles e permita defender suas 
decisões de design da melhor forma possível. Utilize esse modelo como 
uma ferramenta para ajudar você a se comunicar com os stakeholders, 
manter a sua sanidade e promover a melhor experiência possível aos 
usuários. 
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The IDEAL Response 


identity the protierms 


Describe your solution 


Empathize with lhe user 


Agpesi to the business 


Lock in agreement 


Faça o download de uma folha de trabalho em branco para escrever sua 
própria resposta IDEAL acessando o meu site: Attp://tomgreever.com/resources. 
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Faça o follow up depois 


À reunião 
Fazer o 


Entender Ouvir Responder follow-up 


O ea eee ef) 


Quando a reunião terminar, você ainda terá muito trabalho a fazer. O 
momento logo após uma reunião é quase tão importante quanto a própria 
reunião; portanto, não saia correndo, deixando todos para trás. Espere e 
converse depois com as pessoas para fazer um balanço da reunião e obter 
insights que não estavam evidentes na ocasião. De modo informal, converse 
individualmente com as pessoas que possam ajudar a defender a sua causa 
e, em seguida, faça um follow up (acompanhamento) rapidamente, 
enquanto tudo ainda estiver fresco na memória. Esse momento logo após a 
reunião é a sua melhor defesa contra uma tomada de decisão que, em última 
instância, poderia ser desastrosa para a experiência do usuário no projeto. 
Além disso, talvez você consiga resolver alguns problemas, mesmo que 
ache que a decisão já tenha sido tomada. Vamos analisar rapidamente 
algumas atitudes que você deverá tomar logo após a reunião: 


* permanecer no local para conversar com as pessoas; 
e fazer um follow up rápido com as suas anotações; 

* aplicar filtros e remover o que for desnecessário; 

* procurar indivíduos que possam ajudar você; 

* tomar decisões quando houver ambiguidade. 


A reunião após a reunião 


Por qualquer que seja o motivo, as pessoas nem sempre se manifestam e 
dizem o que pensam diante de um grupo. Muitas vezes, é porque o 
propósito é permitir que o(a) chefe diga o que tem para dizer; em outras 
ocasiões, porém, é porque o que as pessoas acham talvez seja impopular ou 
arriscado, e elas não querem perturbar o status quo. Assim, elas esperarão até 


que a reunião termine, chamarão você de lado e dirão o que pensam. É 
incrível a quantidade de decisões que são tomadas logo após uma reunião 
ter sido encerrada. Essa é uma ótima oportunidade de concluir qualquer 
negócio inacabado e trabalhar com quem é influente a fim de obter o apoio 
de que você precisa. 


Popularidade após a reunião 


Às vezes, o corredor do lado de fora da reunião é o lugar mais produtivo 
que há. Eu estava em uma reunião com um executivo para revisar a 
implementação de um design sobre o qual havíamos chegado a um acordo 
antes. A reunião em si correu bem. Não houve nenhum problema sério nem 
nada muito relevante para informar. No entanto, todos permaneceram no 
local e, logo depois, assim que o executivo saiu, vieram especificamente 
falar comigo. 


Uma pessoa me pediu que a mantivesse no circuito no futuro para que ela 
pudesse me apoiar em nossa próxima reunião. Ela queria me ajudar a ter 
sucesso e se mostrava disposta a ser direta quanto a isso. Outra pessoa 
queria voltar atrás em uma decisão anterior e me dar permissão para 
prosseguir, mesmo sem a aprovação explícita daquele executivo. Ele queria 
que o projeto seguisse adiante e estava disposto a arriscar seu pescoço por 
mim. E uma terceira pessoa se desculpou por estar ausente em minhas 
outras reuniões, pediu que me reunisse com ela diretamente para 
compartilhar suas preocupações e prometeu que estaria mais envolvida dali 
em diante. Todas essas três conversas talvez não tivessem ocorrido com o 
mesmo nível de urgência se eu tivesse deixado o local apressadamente. 


Sempre faça planos para permanecer no local por alguns minutos após a 
reunião, conversar com as pessoas, agradecer-lhes pela participação e ver o 
que acontece. Se você trabalha remotamente, poderá permanecer na 
chamada por mais um tempo, ou até mesmo enviar uma mensagem a um 
dos participantes e pedir que fale de suas impressões por alguns minutos. 
Garanto que o nível de atividades fora do horário da reunião será tão alto 
quanto durante a própria reunião. 


Faça um follow up rapidamente 


Assim que for possível (de preferência, dentro de uma hora ou, pelo menos, 
um dia), envie um relatório de follow up para toda a equipe. O relatório não 
precisa ser escrito com perfeição, seu propósito é mais funcional do que 
poético. Você deve fazer o follow up enquanto as informações ainda 
estiverem frescas na memória de todos, inclusive na sua, antes que alguém 
tenha a chance de se esquecer e discordar das decisões que já foram 
tomadas. 


Um follow up rápido demonstra que, para você, a reunião era uma 
prioridade, a ponto de você não fazer mais nada até que ela tenha sido 
totalmente resolvida. Além disso, valoriza os participantes porque mostra 
que você está fazendo o trabalho adicional de mantê-los informados, usando 
o tempo deles da melhor forma possível. Um follow up rápido também 
mostra que você está ouvindo. Todos os feedbacks recebidos não serão 
simplesmente descartados: você os anotou, está levando-os a sério e está 
comunicando-os para toda a equipe de forma concreta. Por fim, o relatório 
de follow up faz com que todos estejam sincronizados quanto ao que foi 
decidido para que não haja nenhuma confusão a partir desse momento. Você 
está criando um registro que todos possam ver e está dando às pessoas a 
oportunidade de replicar caso tenham algum insight adicional. 


Esse registro por escrito se possui um valor inestimável para mim, quando, 
meses mais tarde, pessoas novas no projeto querem saber quem ou quando 
as decisões foram tomadas. Uma pesquisa rápida revela minhas anotações 
ou comunicações, e eu consigo evitar que a discussão se repita. Também já 
tive gerentes que contaram com essas comunicações e as usaram em outras 
reuniões para atualizar diferentes stakeholders. Alguns podem até mesmo 
copiá-las e colá-las em um comunicado diferente para seus próprios chefes. 
A utilização e reutilização do relatório de follow up não podem ser 
subestimadas. 


O follow up deve incluir alguns itens: 
* Em primeiro lugar, agradeça aos participantes da reunião pelo tempo e 


pela participação. Há outras coisas acontecendo na vida das pessoas e 
devemos apreciar o fato de elas dedicarem seu tempo a nós. 


* Em segundo lugar, recapitule tudo que foi discutido. Isso pode ser feito 
por meio de uma lista simples de itens, com a decisão anotada. Ter uma 


lista simples facilita compartilhá-la com outras pessoas. 


e Por fim, mantenha o foco nas ações, nos próximos passos ou nas 
expectativas. Você sempre deve informar (na medida do possível) o que 
vai acontecer a seguir. Isso ajuda as pessoas a verem que participar da 
reunião constituiu um bom uso do tempo delas porque permite que o 
trabalho possa avançar. Também diminui o fardo sobre suas costas e 
permite que a equipe toda participe dos próximos passos. 


Não tenha medo de atribuir tarefas a outras pessoas, mesmo para aquelas 
que estão fora de sua influência imediata. Nas reuniões, é comum que uma 
pessoa se ofereça para investigar algo, pedir informações para outra pessoa 
ou concorde em continuar a conversa em outro lugar. O follow up é o lugar 
perfeito para lembrar a todos sobre quem está fazendo o quê. Seja o mais 
específico possível. Anote o item em questão, mencione a pessoa que será 
responsável por ele e forneça datas ou um prazo geral sobre quando 
saberemos mais. Também faça perguntas diretas para que não haja 
ambiguidade quanto aos itens que continuarem indefinidos. Liste as 
decisões importantes e deixe claro o motivo de a decisão estar sendo 
tomada. 


Eis um exemplo de como poderia ser um relatório de follow up: 
Obrigado a todos pelo seu tempo hoje! Foi uma reunião muito produtiva e 
agradeço o fato de todos terem estado disponíveis. Eis o que decidimos: 
* À transição na página inicial está rápida demais. Jon mudará isso para 100 ms. 


* O preço dos itens em Best Sellers (Mais Vendidos) parece estar muito pequeno. 
Verificarei para garantir que esteja consistente com os demais e farei ajustes se 
for necessário. 


* À árvore de categorias parece que está usando dados incorretos. Enviaremos um 
email para Abdul para resolver isso. 

* Stan está preocupado achando que a CTA para adesão é grande demais e está 
usando a cópia de texto incorreta. Jennifer está verificando qual é a cópia correta 
Junto à área de conteúdo. Encaminharei o estudo de usabilidade que dá base para 
isso. 

* À data do lançamento foi aprovada, QA pendente. Jon nos enviará um email 
amanhã com uma atualização do status. 


O ponto importante, nesse caso, é manter a sua atualização a mais breve e 
específica possível, sem deixar nenhuma informação de fora. Seus 


stakeholders devem ser capazes de passar rapidamente os olhos no relatório, 
sem que fiquem imersos nos detalhes. Se precisarem de mais informações, 
poderão acessar um link com suas anotações completas e a documentação. 


Aplique filtros 


Outra estratégia pós-reunião é usar todo o seu discernimento para filtrar e 
excluir todas as informações desnecessárias, que não valham a pena ser 
repetidas para toda a equipe. Isso pode ser difícil de avaliar, mas será 
necessário, se esperamos nos comunicar sem que haja muitos dados 
irrelevantes. Há muitas informações ditas em uma reunião que não precisam 
ser reconsideradas, rediscutidas ou repetidas. Boa parte delas será evidente, 
mas, para outras, será mais difícil julgar. 


Por exemplo, se a maioria das pessoas na sala fizer um sinal afirmativo com 
a cabeça diante da solução correta, porém uma ou duas pessoas ainda 
tiverem dúvidas, permita que elas digam o que estão pensando. Deixe que 
falem; ouça e aplique todas as mesmas habilidades que você aprendeu a 
usar até agora. Contudo, na hora de fazer suas anotações ou criar o relatório 
de follow up, use seu próprio discernimento para decidir se é necessário 
documentar essas informações. Algumas discussões podem ficar 
seguramente fora do radar, e isso não será um problema. 


Em outras ocasiões, talvez haja um colega ou um stakeholder que diga algo 
ou faça sugestões que não sejam totalmente relevantes. Relacionado à ideia 
de que as pessoas gostam de ouvir a si mesmas falarem, algumas pessoas 
simplesmente vão insistir em uma ideia. Tudo bem. Acontece com muita 
frequência. Algumas pessoas podem chamar isso de brainstorming, mas, em 
geral, estará claro que essa pessoa está se desviando do assunto. Mas tudo 
bem. Permita que ela fale. Valorize suas contribuições no processo. O 
importante é que você reconheça essas situações e as leve em consideração 
em seu relatório de follow up, excluindo discretamente quaisquer 
informações que apenas acrescentariam dados irrelevantes à discussão. 


Ignorando a “inovação” 


Certa vez, eu estava em uma reunião com um cliente, discutindo a ideia de 
um mapa interativo para as lojas de varejo do cliente. O mapa existente 


nada mais era do que uma imagem estática, com nomes que o usuário podia 
diminuir e aumentar. Enquanto revisávamos alguns dos designs do mapa, o 
gerente do projeto mudou a direção da conversa, falando de como esses 
mapas não eram suficientemente inovadores, que ele esperava mais de nós e 
queria saber onde estavam nossas ideias “fora da caixa”. Ele, então, 
começou a falar pomposamente de um mapa 3D, no qual o usuário poderia 
andar pelos corredores das lojas e, usando realidade aumentada, poderia ver 
todos os detalhes de cada produto nas prateleiras, com pop-overs e 
animações. Embora sua intenção fosse boa, eu sabia muito bem que não 
deveria perder meu tempo com essa ideia e consegui remover essa parte da 
reunião de minhas anotações para o follow up. 


Para ajudar a entender quais são as informações que podem ser filtradas e 
excluídas de forma segura, você deve avaliar rapidamente vários aspectos 
acerca da pessoa que está dando o feedback: 


Quais são as intenções dessa pessoa? 
Algumas pessoas simplesmente jogam as ideias casualmente e não têm 
nenhuma intenção de vê-las indo para qualquer lugar. Elas se sentem à 
vontade com o fato de a ideia não ter continuidade, isto é, de não 
avançarem para além da sugestão inicial. 


Há outras pessoas que concordam ou discordam? 


Em geral, estará claro que ninguém mais concorda com essa pessoa e, 
mesmo que não haja uma decisão, você poderá seguir em frente com 
segurança, sem adicionar essa ideia às suas anotações. Faça uma leitura da 
sala e avalie. 


Essa pessoa exerce influência ou não? 
Algumas pessoas são mais influentes e importantes para a nossa tomada 
de decisão. Descubra quem é quem e, então, utilize isso para dar base às 
suas decisões no que diz respeito ao follow up. 


É provável que essa pessoa levante esse assunto novamente na próxima 
reunião? 
Em caso afirmativo, você precisará de uma maneira de adiar a decisão de 
forma educada e fazer o follow up depois. Se você realmente não quer que 
esse assunto surja novamente, certifique-se de abordar a ideia antes que 


isso aconteça. 


A questão importante, nesse caso, é que é possível ignorar algumas das 
informações da reunião, impedindo que ela atrapalhe a sua documentação 
ou o projeto. Precisamos aprender a reconhecer as ocasiões em que os 
comentários das pessoas não estão alinhados aos objetivos do projeto. Se 
essas pessoas não forem uma parte influente na decisão, ninguém mais 
concorda com elas e é pouco provável que tragam o assunto à tona 
novamente. Tirar esse item do follow up será uma aposta segura. 


Nunca mencione o assunto novamente 


Eu estava em uma reunião com cinco ou seis pessoas e havia uma pessoa 
que era particularmente carismática. Ele não era da mesma equipe, mas era 
uma pessoa influente na empresa e pediu que fosse incluído em nossa 
discussão. De modo geral, eu diria que, embora todos gostassem de 
trabalhar com ele (era uma pessoa divertida para se ter por perto), essa 
pessoa também tinha uma reputação de ter muitas ideias malucas. 


No decorrer da reunião, outra pessoa estava fazendo comentários sobre uma 
interação quando ele veio com uma ideia. Sua ideia tomou uma forma 
extremamente não convencional, era praticamente impossível de 
implementar ou, no mínimo, estava muito fora da realidade, e, por um 
momento, toda a discussão se transformou em um brainstorm exaltado. Não 
participei dessa discussão, apenas fazia anotações e perguntas. Outros se 
manifestaram, mas, para mim, estava claro que ninguém mais achava que 
essa ideia fosse realmente uma prioridade. Sua ideia estava fora do escopo 
do projeto, ainda que fosse muito criativa e, sem dúvida, futurista. 


Após a reunião, quando estava escrevendo meu relatório de follow up, 
cheguei à seção de minhas anotações que continha essa ideia. Em vez de 
mantê-la viva e incluí-la na agenda para a próxima reunião, optei por deixá- 
la totalmente de fora do follow up. Enviei um email a todos os que estavam 
na sala, incluindo essa pessoa, com uma lista de itens sobre os quais 
havíamos discutido, mas excluí propositalmente essa ideia. Depois disso, 
não ouvi mais nada sobre ela. Ninguém mais na equipe a mencionou, e ele 
tampouco jamais voltou a falar no assunto. 


Nesse caso em particular, eu precisava entender a dinâmica dos 


relacionamentos em jogo na sala; caso contrário, poderia ter me deparado 
com uma requisição com o potencial de nos distrair completamente. Apesar 
disso, é importante enfatizar que tomei duas atitudes para que ele se sentisse 
bem no momento: fiz perguntas e tomei notas. Ele não tinha ideia do que eu 
estava escrevendo; na verdade, não era importante. O que importa é que eu 
o respeitei bastante, a ponto de ouvi-lo e fazer anotações. Fiz com que ele 
se sentisse valorizado. Mesmo que ele tivesse notado que eu havia excluído 
a sua ideia do follow up, ele sabia que, ao menos, eu a havia considerado. 
Não sei ao certo, mas meu palpite é que ele nem chegou a ler o email, ou 
nem mesmo percebeu que sua ideia não estava lá. 


De modo geral, você deve aprender a filtrar e excluir todos os itens 
irrelevantes que possam atrapalhar a sua tomada de decisões. É muito fácil 
pensar que as opiniões e as ideias de todos devem ser incorporadas em 
nossos designs, mas isso não é verdade. Na realidade, esse é um caminho 
perigoso. Utilize suas habilidades para ouvir e faça uso de seu 
discernimento sobre os relacionamentos para remover as informações que 
não são necessárias, mantenha os itens mais importantes e faça o follow up 
rapidamente com o que será feito. 


Procure indivíduos que possam ajudar 


Assim como na reunião após a reunião, talvez haja algumas pessoas com 
quem você queira conversar depois. Você poderia se oferecer para 
acompanhá-las até suas mesas, convidá-las para continuar a conversa mais 
tarde no café ou enviar-lhes uma mensagem direta para fazer um balanço da 
conversa depois. É importante que você faça isso logo após a reunião, 
enquanto todos ainda estiverem com a discussão fresca na memória e 
estarão pensando em seu projeto. Quando voltarem para suas mesas, será 
muito mais difícil que eles tenham tempo para você. 


O propósito dessas conversas individuais é dar às pessoas uma 
oportunidade para que elas compartilhem seus pensamentos e opiniões fora 
do âmbito de uma reunião, quando há outras pessoas ouvindo. Você pode 
usar esses relacionamentos interpessoais para obter mais informações sobre 
o projeto, ter insights sobre as dinâmicas da equipe ou da empresa, as quais 
talvez você desconheça, e construir novos relacionamentos que ajudarão 


você a obter o que precisa no futuro. Essas pessoas exercem influência em 
seu projeto e podem fazer parte de sua coalizão para influenciar a próxima 
reunião e a próxima rodada de revisões de design. 


Em geral, as reuniões são um bom momento para ver as pessoas com quem 
você, habitualmente, não interage com regularidade. Elas podem ser de 
outro departamento ou equipe; portanto, acabam por não ver tudo que você 
está fazendo. Sempre fico agradavelmente surpreso quando alguém que eu 
não conheço muito bem vem em minha ajuda e expressa seu apoio pela 
minha proposta. Procure deliberadamente essas pessoas e encontre meios de 
se conectar com elas com mais regularidade a fim de mantê-las no circuito; 
assim, elas terão uma oportunidade para ajudar a influenciar o seu trabalho. 


Faça algo, mesmo que esteja errado 


Quando eu era criança, meu pai e eu construímos uma casa na árvore 
juntos. Eu me lembro de uma ocasião em que, enquanto segurava uma 
tábua, meu pai derrubou suas ferramentas. Ele estava de pé em uma escada, 
segurando a tábua pesada em sua posição, incapaz de fazer algo sozinho. Eu 
não sabia o que fazer e apenas fiquei ali, olhando para ele, indeciso. Eu 
deveria ajudá-lo a segurar a tábua? Deveria pular e pegar as ferramentas? O 
que eu deveria fazer? Depois de alguns segundos de agonia, meu pai gritou 
para mim: “Ei, faça algo! Mesmo que esteja errado!”. Na verdade, essa era 
uma frase comum do meu pai. O sentimento é que, às vezes, não está claro 
o que devemos fazer, mas, quase sempre, será melhor fazer algo a não fazer 
nada. 


Eu não sugeriria aplicar essa lógica em muitas decisões importantes da 
vida, mas é comum que as reuniões terminem sem uma resolução clara para 
algumas das questões mais importantes de nossos designs. Às vezes, 
mesmo quando pressionamos bastante para fazer com que as pessoas 
tomem decisões, não conseguimos que todos concordem ou sigam adiante. 
Pode ser que ninguém esteja disposto a falar na frente de outros 
stakeholders. Talvez ninguém realmente se importe com um elemento 
específico. É comum estar em uma situação em que nenhuma solução óbvia 
pareça ser o curso correto de ação. Ninguém tem realmente certeza do que 
fazer e, desse modo, ninguém faz nada. 


Nesses casos, recomendo simplesmente tomar uma decisão por conta 
própria e comunicá-la ao resto da equipe em seu follow up. É melhor fazer 
algo (mesmo que esteja errado) e dar à sua equipe a oportunidade de se 
manifestar contra ou a favor de sua escolha, em vez de lidar com indecisões 
e um processo de design estagnado. Às vezes, você só precisa decidir e 
dizer a todos o que fará para que as pessoas se manifestem. 


Há uma ideia semelhante, chamada de teoria do McDonald's, proposta por 
Jon Bell. Se você já passou pela experiência de estar com alguns amigos 
tentando decidir um lugar para comer, você conhece essa sensação. Todos 
tentam ser educados, mas ninguém parece realmente se importar com o 
restaurante a que irão. Como resultado, todo mundo continua lá, de pé, sem 
ir a lugar nenhum. De acordo com a teoria de Jon, você deve sugerir comer 
no McDonald's — tome a decisão pelo grupo — e, de repente, todos terão 
uma opinião sobre aonde ir. Jon Bell diz o seguinte: “Anne Lamott! é a 
favor de “versões preliminares péssimas”, a Nike nos diz: “Just Do If”, e eu 
recomendo o McDonald's somente para as pessoas se sentirem tão 


ultrajadas que apresentarão uma ideia melhor” 2 


Um amigo desenvolvedor, Mark, faz o mesmo com estilos CSS em seus 
projetos. Como não é designer (e não é muito bom com CSS), ele quer ter 
certeza de que os designers farão algo melhor. No entanto, Mark já havia 
passado por várias experiências em que seu CSS era visto como 
“suficientemente bom” e jamais chegava a ser aperfeiçoado até o ponto em 
que ele sabia que deveria ser. Em vez de explicar a todos o que precisa ser 
feito, ele simplesmente aplica cores horríveis em todos os elementos: 
vermelho-vivo, rosa-choque ou marrom-pútrido, para garantir que todos 
que as vejam insistam em estilizá-las novamente, de modo apropriado. 
Muitas vezes, a melhor maneira de chamar a atenção das pessoas é tomar 
uma decisão claramente ruim. 


O mesmo acontece com as decisões de design. Ninguém tem certeza da 
solução correta, mas todos querem ser educados. Afinal de contas, esses 
designs são seus, e as pessoas talvez não queiram magoar você. Se você se 
vir diante de indecisões ou de ambiguidades, assuma a liderança e tome a 
decisão por todos. Encontre a opção que você acredita ser a melhor e, então, 
comunique-a à equipe. Seja específico, forneça exemplos e dê às pessoas 
um prazo. Diga algo como: “Se eu não receber nenhuma resposta de vocês 


até o fim do dia, prosseguirei com esse design”. Talvez ninguém responda, 
mas, às vezes, as pessoas, de repente, terão opiniões fortes e permitirão que 
a solução correta seja discutida. Não é uma ciência exata, mas é uma ótima 
maneira de fazer com que seus designs avancem. Lembre-se disto: faça 
algo, mesmo que esteja errado. 


É importante ter em mente que, mesmo que a reunião tenha terminado, seu 
trabalho não estará concluído. Muitas vezes, as partes mais produtivas da 
reunião ocorrem depois que todos saíram da sala. Não perca essa 
oportunidade de finalizar as decisões e conseguir a adesão das pessoas 
depois de encerrada a reunião. Tenha em mente as dicas a seguir para 
quando a reunião tiver terminado: 


* O momento logo após a reunião é uma ótima oportunidade para ouvir o 
que as pessoas realmente pensam. 


* Quanto mais rápido você fizer o follow up, melhor será para comunicar 
a urgência, a importância e a necessidade de tomar decisões. Faça isso 
agora. 


e Filtre e exclua quaisquer excessos ou recomendações desnecessárias de 
suas anotações, os quais você sabe que não exigirão ações no futuro. 


* Permaneça no local para conversar, acompanhe as pessoas de volta às 
suas mesas e obtenha a adesão de última hora de que você precisa para 
seguir em frente. 


* Se houver ambiguidades, tome uma decisão e a comunique para todos os 
demais. Essa talvez seja a única maneira de fazer com que o projeto 
avance. 


A questão principal no que diz respeito a reuniões e decisões de design é 
que elas nem sempre ocorrem do modo que queremos. Mesmo com a mais 
eloquente das respostas e o melhor follow up, talvez ainda seja necessário 
fazer mudanças em nossos designs das quais discordamos. No entanto, se 
você sair de uma reunião com a sensação de que tudo está perdido, não se 
preocupe. Ainda será possível salvar o dia e retrabalhar seus designs de 
modo a atender às necessidades de todos, sem perder totalmente o seu 
trabalho. Você precisa aprender a lidar com as mudanças. 


1 N.T.: Anne Lamott é escritora, ativista política e professora de redação. Entre suas 


obras, destaca-se Bird by Bird: some instructions on writing and Life [edição publicada no 
Brasil: Palavra por Palavra: instruções sobre escrever e viver (Sextante, 2011)], sobre a arte 
de escrever. 


2 Jon Bell, “McDonald's Theory” (A teoria do McDonald's), 29 de abril de 2013, 
http://bit.ly/1 EngiOD. 
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Lidando com mudanças 


Depois de tudo que discutimos, gostaria de ser franco e dizer que, às vezes, 
não importa o quanto tentemos, ainda teremos de fazer mudanças das quais 
discordamos em nossos designs. Talvez as pessoas com quem trabalhamos 
não estejam dispostas a mudar suas opiniões, apesar de nossas sugestões 
como especialistas, ou é possível que não tenhamos feito um trabalho 
suficientemente bom de convencimento quanto aos nossos designs. Neste 
capítulo, proponho algumas opções para lidar com as mudanças. 


Discutiremos o seguinte: 


* explicações comuns para os motivos de essa situação acontecer; 


* ver uma oportunidade nessas mudanças, não importa quão ruim possam 
parecer; 


* como escolher suas batalhas e ganhar um crédito de confiança; 
* aprender a reconhecer quando você está errado e se corrigir; 


e definir expectativas apropriadas para o que nossos stakeholders podem 
esperar a partir de agora. 


Inicialmente, vamos falar sobre o motivo de termos acabado nessa posição. 


As mudanças são o propósito, certo? 


Conforme destacamos no início do livro, há algo no design que parece 
provocar opiniões subjetivas de todos. Todos são designers! Contudo, mais 
do que isso, a própria apresentação de nosso trabalho a stakeholders que 
não são designers parece se tratar totalmente da apresentação de uma 
plataforma para sugestão de mudanças. Muitas vezes, essas reuniões têm 
títulos no calendário de eventos como “Revisão de design”, ou nós dizemos 
verbalmente aos stakeholders que queremos o feedback deles. Como 
resultado, os stakeholders chegam à reunião com a expectativa de que dizer 
a nós que devemos mudar algo é o propósito da reunião! Caso não 
proponham mudanças, a reunião não teria sentido. Certo? Esse fenômeno 


fez surgir algumas ideias muito interessantes: 


Lei da Trivialidade de Parkinson 


Esse problema é muito influenciado pela Lei da Trivialidade de Parkinson, a 
qual afirma que as pessoas em uma reunião gastarão uma quantidade 
desproporcional de tempo com problemas que não são essenciais ao 
projeto. De acordo com a Wikipédia, “Parkinson observou e mostrou que 
um comitê cujo trabalho era aprovar os planos para as instalações de uma 
usina nuclear gastou a maior parte de seu tempo com discussões inúteis 
sobre problemas relativamente triviais e sem importância, porém fáceis de 
entender, por exemplo, quais materiais deveriam ser usados para o abrigo 
de bicicletas dos funcionários, ao mesmo tempo que negligenciou o 
próprio projeto proposto para as instalações da usina, muito mais 
complexo” 1 É daí que surgiu o termo “bike-shedding” (abrigo para 
bicicletas) no desenvolvimento de software. Às vezes, as pessoas dão 
feedbacks e gastam uma quantidade extraordinária de tempo discutindo 
um problema relativamente pequeno porque esse problema é visível e 
acessível à sua compreensão. 


Desenhando um pato 


O problema também criou oportunidades para os designers encontrarem 
maneiras criativas de contornar essas situações, como o recurso de 
desenhar um pato. De acordo com Jeff Atwood, um pato é “um recurso 
adicionado por nenhum outro motivo além de chamar a atenção da 
gerência e ser removido, evitando, assim, mudanças desnecessárias em 
outros aspectos do produto” 2? O conceito tem origem em uma história da 
Interplay Entertainment. Um dos designers de um jogo de xadrez animado 
estava cansado de todas as mudanças solicitadas pelos seus stakeholders. 
Parecia que, não importava o que fizesse, eles sempre pediam mais uma 
mudança. Para evitar fazer outras mudanças, o designer criou a 
personagem da rainha e as animações exatamente como queria que 
fossem, mas também deu à rainha um pato de estimação. O pato era 
irritante, exagerado e voava por todo lado na tela. De acordo com o 
Coding Horror: “Em certo momento, chegou a hora de o produtor revisar 
o conjunto de animações da rainha... Quando as animações estavam 
prontas, ele se virou para o artista e disse: Parecem ótimas. Só mais um 


detalhe: livre-se do pato” 2 


Braços peludos 


Mas espere: tem mais! Ideias como essa existem há muito tempo. Nos 
anos 40, os animadores da Disney criaram uma solução parecida. Seus 
diretores de arte gostavam de sugerir mudanças, e desenhar e redesenhar 
cada personagem era um processo trabalhoso. Assim, para evitar fazer 
alterações das quais discordassem, os animadores começaram a 
acrescentar pelos nos braços dos personagens que eles não queriam que 
fossem aprovados, enquanto deixavam limpos os designs que 
recomendavam. Nos anos 40, as pessoas não queriam um personagem de 
desenho animado com pelos no corpo, e essa tendência inconsciente 
levava seus diretores de arte a rejeitarem esses personagens. Desde então, 
a expressão “braços peludos”4 tornou-se conhecida como uma tática para 
fazer com que outra pessoa concorde com você usando distrações criadas 
propositalmente. 


(1 
' ni ) 


Peço desculpas se você ficar muito distraído com esse pato e não conseguir se concentrar na leitura 2 


Planeje discussões melhores 


Obviamente £ não devemos enganar nem manipular nossos stakeholders 
dessa forma, mas há certas verdades nessas histórias que merecem ser 
consideradas em nosso trabalho. Algumas pessoas não ficarão satisfeitas, 
não importa o que façamos, e precisamos descobrir uma forma de ajudá-las 
sem comprometer a integridade da experiência dos usuários. Criar braços 
peludos e desenhar patos pode ser histórias engraçadas, mas elas também 
mostram um ponto interessante: todos os relacionamentos dizem respeito a 
dar e receber. Devemos reconhecer padrões em que seja apropriado oferecer 


soluções e empregar métodos para manter o foco de nossas discussões na 
tarefa de obter apoio. 


Muitas vezes, esses tipos de problema podem ser evitados simplesmente 
planejando discussões mais apropriadas por meio de uma definição 
adequada do contexto e da fidelidade de nosso trabalho, além de dizer aos 
nossos stakeholders quais são os tipos de feedback que seriam úteis e quais 
não seriam. Conforme vimos no Capítulo 3, definir o contexto para eles 
com antecedência é importante a fim de evitar esses problemas. Se você se 
vir respondendo a feedbacks indesejados, esse poderia ser o motivo. 


O que está realmente acontecendo? 


Apesar de tudo, ser solicitado a fazer mudanças das quais discordamos é 
exatamente o que estamos tentando evitar. Nós nos esforçamos bastante 
para ouvir e entender nossos stakeholders a fim de podermos recorrer às 
necessidades deles em nossa resposta. Se eles ainda discordam ou insistem 
que façamos uma mudança, há alguns motivos que podem explicar isso. 


Há um mal-entendido 


Se você está confuso com a insistência de seu stakeholder sobre uma 
mudança a qual você não recomenda fazer, é possível que vocês 
simplesmente não estejam na mesma sintonia. Pode ter havido um problema 
de comunicação: seu stakeholder não entendeu o que era um controle do 
tipo carousel (carrossel), não estava ouvindo com tanta atenção ou não 
compreendeu bem o contexto. Em geral, esclarecer as falhas de 
comunicação será suficiente. Em outras ocasiões, o objetivo estabelecido 
para o projeto pode ter mudado e se transformou com o passar do tempo e, 
agora, estamos resolvendo problemas diferentes daqueles que nos 
propusemos a solucionar originalmente. Isso é muito comum, e a sugestão 
de um stakeholder para fazer alterações, muitas vezes, é um reflexo dessa 
mudança de objetivos. Identificar a causa-raiz e redefinir claramente os 
objetivos ajudará vocês a voltarem a uma situação mais propícia. 


Seus designs não são a melhor solução 


Sei que é difícil de engolir, mas é possível que seu design, na verdade, não 


seja a melhor opção. Com efeito, você poderia estar totalmente enganado. 
Mais adiante, neste capítulo, veremos como entender quando você está 
errado, mas é importante perceber que nossos stakeholders e líderes foram 
colocados em uma posição de autoridade por um motivo, e geralmente eles 
são, em última instância, responsáveis pelos nossos sucessos e fracassos. 
Nossos stakeholders têm conhecimento especializado em diferentes áreas, 
além de insights sobre os negócios que nós não temos. Do mesmo modo 
que eles confiam em nós para recomendar as melhores soluções, também 
devemos aprender a ter a mesma confiança neles quando se trata da decisão 
final. Talvez não seja fácil, mas é a nossa realidade. 


Eles têm uma necessidade que não está sendo atendida 


Algumas pessoas — particularmente os executivos — simplesmente querem 
saber se aquele item que é importante para elas está presente. Sei que é uma 
atitude que não está centrada no usuário do modo como gostaríamos que 
estivesse. Talvez seja algo que clientes importantes ou outros executivos 
requisitaram. Desde que saibam onde está a funcionalidade que desejam, 
em geral os stakeholders ficarão satisfeitos. Eles podem se sentir totalmente 
satisfeitos mesmo que haja alguns passos adicionais para acessá-la, se 
souberem o que esperar. Trabalhei com uma pessoa que gostava muito de 
observar todas as conversas sobre o aplicativo nas redes sociais e insistia 
que as adicionássemos na página inicial. Na verdade, ele só precisava ter 
um acesso rápido a elas. Ajudá-lo a usar um marcador (bookmark) com um 
URL intuitivo, que ele pudesse se lembrar, atendeu às suas necessidades. 


No entanto, o problema nem sempre será tão simples assim. Entender as 
necessidades de nossos stakeholders era o objetivo do Capítulo 2. Se você 
suspeita que há alguma necessidade subjacente que não está sendo expressa 
pelo seu stakeholder, será preciso trabalhar com mais afinco para descobrir 
suas motivações e encontrar uma forma de atender a essas necessidades. 


Eles não são nem um pouco razoáveis 


Eles apenas não são razoáveis? Talvez, mas provavelmente não. Sim, 
algumas pessoas não são razoáveis e, não importa o que possamos dizer, 
elas insistirão que façamos do jeito delas. Algumas pessoas agirão em favor 
de seus próprios interesses, mesmo que involuntariamente. Estima-se que 


4% da população sejam sociopatas clínicos.” Isso significa que 4% de todas 
as pessoas se utilizam de desonestidade e manipulação para controlar as 
pessoas à sua volta. Todavia, o que realmente separa os sociopatas é o fato 
de eles fazerem isso sem sentir remorsos. Eles se comportam dessa forma 
sem ter um senso de moral, empatia ou preocupação sobre como as decisões 
deles afetam outras pessoas. 


Além disso, é quatro vezes mais provável que personalidades sociopatas 
ocupem funções executivas em empresas É Não estou dizendo que seu CEO 
possa ser um assassino em série, pois as tendências dos sociopatas nem 
sempre se manifestam de formas violentas. Pense nisso. Há pessoas que são 
orientadas a tarefas e pelo sucesso, talvez à custa de outras. É difícil tomar 
decisões importantes nos negócios se você tiver empatia para considerar 
cuidadosamente o modo como suas decisões afetarão todos os demais, não 
é mesmo? Sem dúvida, algumas pessoas podem estar na extremidade do 
espectro e são manipuladoras e mentirosas, mas muitas pessoas em cargos 
executivos chegaram aonde estão porque, de forma bem-sucedida, foram 
capazes de remover a emoção da equação em seus relacionamentos. O 
efeito colateral é que, quando tomam decisões, nem sempre elas parecem 
ser racionais para nós. Conhecer esse fato implica que talvez seja necessário 
ter um pouco de cautela ao trabalhar com essas pessoas. 


No entanto, isso é menos comum do que poderíamos imaginar. É 
improvável que seu stakeholder não seja nem um pouco razoável. Em geral, 
quando achamos que nossos stakeholders não estão sendo razoáveis, é 
porque nós simplesmente não vemos a situação do ponto de vista deles, e é 
possível (e até mesmo provável) que tomássemos a mesma decisão se 
estivéssemos em seus lugares. Muitas vezes, uma sugestão, que 
supostamente não parece razoável, tem suas raízes em algo muito mais 
simples: as pessoas querem apenas ser ouvidas. 


As pessoas querem saber que estão sendo ouvidas 


Acredite ou não, esse pode ser um dos motivos mais comuns (e menos 
falados) pelos quais as pessoas insistem em fazer mudanças. Nossos 
stakeholders simplesmente querem saber que suas ideias e sugestões estão 
sendo ouvidas e consideradas com seriedade. Muitas pessoas que não 
parecem ser razoáveis apenas não se sentem confiantes de que ouvimos o 


que elas disseram e, desse modo, não veem outra solução a não ser impor a 
sua própria agenda ou mostrar quem é que manda. 


Bem, as pessoas com cargo de autoridade esperam ter autoridade!? Elas 
esperam que as opiniões delas sejam tão válidas quanto as suas; portanto, 
descartar as ideias dessas pessoas com uma explicação sobre as suas 
próprias decisões soa como uma desculpa. Parece que você está invalidando 
o ponto de vista delas. Se você se recusar a fazer mudanças, mesmo que 
indiretamente, é sinal de que você não as estaria ouvindo. Não é de se 
surpreender que elas não pareçam ser razoáveis e insistam em fazer 
mudanças das quais você discorde. Você não deu a elas nenhuma outra 


opção para serem ouvidas. 


Com isso, não estou sugerindo que nossos stakeholders sejam tão 
arrogantes a ponto de imporem a sua própria agenda de propósito. Acho que 
isso pode acontecer inconscientemente, quando eles não se sentem 
valorizados no processo. Se isso estiver acontecendo, precisamos dizer a 
eles o quanto valorizamos suas contribuições e feedbacks. Eles poderiam 
achar que descartamos sua sugestão sem considerá-la seriamente. O mais 
importante, porém, é que nós não os ajudamos a entender por que a nossa 
solução é preferível. Você terá de voltar e pedir que eles expliquem seus 
pontos de vista novamente. 


Fazendo uma limonada 


Nem sempre a “ideia ruim” de uma pessoa será péssima e arruinará tudo. 
Em geral, é a nossa execução ruim dessa ideia que faz com que essas 
mudanças gerem caos. Em vez de tentar lutar contra ela ou de fazer o 
trabalho difícil de melhorá-la, geralmente nós desistimos, encolhemos os 
ombros e acrescentamos o que a pessoa quer, exatamente como foi 
proposto. No entanto, se fizermos isso, perderemos uma grande 
oportunidade de melhorar o design de um modo que jamais havíamos 
pensado antes. 


Todo design tem restrições e limitações. Nosso desafio sempre foi criar sites 
ou aplicações que sejam fáceis de usar, mas devem oferecer suporte a um 
determinado conjunto de funcionalidades, histórias de usuários ou obedecer 
a grandes restrições, como o tamanho limitado da janela de exibição dos 


dispositivos móveis. Adoramos esses desafios. É isso que nos faz sair da 
cama todos os dias: fazer ótimos trabalhos, apesar das restrições. Se nossos 
projetos não tivessem nenhuma restrição, teoricamente, seria mais fácil, 
mas não seria, nem de longe, tão gratificante. O fato é que essas restrições 
nos tornam melhores como designers. Elas são o motivo pelo qual temos 
um emprego; outras pessoas não conseguiriam descobrir como fazer tudo 
funcionar, dados os mesmos requisitos. Assim, quando somos levados a 
implementar uma decisão de design da qual discordamos, é importante não 
desistir e simplesmente jogá-la na interface — por mais tentador que isso 
possa ser. 


Fazer essas alterações é uma oportunidade para descobrir a melhor maneira 
de implementar essa ideia. É uma nova restrição que está sendo solicitada a 
ser incorporada por você no projeto. Nossos stakeholders esperam que 
vamos “descobrir a melhor maneira de fazer isso” porque é para isso que 
somos pagos. Com efeito, nosso objetivo deveria ser usar essa restrição para 
melhorar a experiência do usuário, em vez de fazer o trabalho de qualquer 
Jeito, esperando não causar problemas. Devemos mudar totalmente essa 
atitude e enxergar uma oportunidade na confusão. Podemos melhorar a 
aplicação e fazer uma discussão com soluções mais inteligentes e um 
raciocínio criativo. 


Com base em minha experiência, a sugestão de uma pessoa é uma mina de 
ouro para outras ideias à espera de serem escavadas. As mudanças 
propostas pelo seu stakeholder devem servir de centelha para uma discussão 
que leve a uma solução melhor ainda. Seu trabalho como comunicador é 
conduzir essa conversa para uma direção que leve aos melhores resultados 
para a sua aplicação. Você pode conseguir isso fazendo perguntas, 
entendendo o ponto de vista dos stakeholders e ouvindo, ou seja, 
empregando todas as habilidades que discutimos nestas páginas. Envolva 
outras pessoas. Pergunte como elas resolveriam o mesmo problema. 
Proponha uma alternativa. Até mesmo uma alternativa ruim deve dar início 
a uma discussão sobre as soluções. Perceba que essa é uma oportunidade 
para você colocar em prática suas habilidades como comunicador e liderar 
uma discussão sobre como preservar uma experiência apropriada aos 
usuários de modo eficaz. 


Descobrindo outros problemas 


Ocasionalmente, ter um stakeholder insistindo sobre uma mudança pode 
levar você a melhorar a aplicação de um modo jamais esperado, resolvendo 
problemas que, do contrário, talvez não tivessem sido percebidos. Um 
aplicativo móvel cujo design eu fiz exibia dados demográficos tanto em 
uma view de lista como em uma view de gráfico de barras, controladas por 
abas. Originalmente, as duas views eram bem distintas, mas, com o tempo, 
a equipe mudou alguns itens de lugar, e as duas views, involuntariamente, 
tornaram-se parecidas, sem que tivéssemos percebido. Por fim, o cliente nos 
pediu que adicionássemos outro campo no gráfico de barras e percebemos 
que era possível combinar as duas views em uma só. O que havia começado 
como duas formas diferentes de mostrar as informações foi combinado em 
uma só view consolidada, simplificando a experiência para o usuário final. 
Se tivéssemos argumentado contra todas essas mudanças, jamais teríamos 
chegado a uma solução melhor. 


Em outro projeto, uma de minhas stakeholders solicitou mudanças em 
algumas interações de validação de formulário e mensagens. Embora suas 
intenções fossem boas, achei que as mudanças prejudicariam a experiência 
do usuário. Em vez de concordar cegamente, nossa equipe fez alguns testes 
rápidos com usuários para garantir que o que estávamos fazendo iria 
funcionar. Ao observar os usuários executando todas as tarefas de ponta a 
ponta, descobrimos um problema totalmente diferente no fluxo do usuário. 
O fato é que nem minhas sugestões nem aquelas do cliente teriam 
funcionado. Estar aberto a mudanças em uma parte da aplicação revelou 
uma falha em outra parte. Por causa do nosso cronograma, se eu não 
estivesse aberto às sugestões de meus stakeholders, talvez não tivéssemos 
descoberto aquele problema tão cedo. 


Encarar as solicitações dos stakeholders como uma oportunidade para 
mudanças ou um desafio a ser resolvido é uma abordagem muito mais 
saudável do que se acomodar resmungando. Planeje-se para essas mudanças 
porque elas irão acontecer. Se você já sabe como vai abordá-las — por 
exemplo, com recursos previamente planejados, um estudo de usuário extra 
ou uma reavaliação da abordagem —, estará em uma posição muito melhor 
para garantir que proporcionará a melhor experiência possível aos usuários, 
mesmo diante de mudanças difíceis. Seus stakeholders apreciarão seus 


esforços, sua atitude ajudará você a permanecer no caminho certo e, no fim, 
o usuário agradecerá. 


A conta bancária da confiança 


À medida que considerar os diferentes modos de abordar o feedback dos 
stakeholders, é importante perceber que todo relacionamento envolve dar e 
receber. Simplesmente não é possível ter uma relação saudável com outras 
pessoas se essa relação for unidirecional. Não se pode esperar que outras 
pessoas deixem de fazer sugestões para mudanças. Consequentemente, você 
deve estar preparado para lidar com elas. É muito melhor se antecipar e 
saber como reagir a essas mudanças antes que elas ocorram. 


De um ponto de vista estritamente econômico, seu trabalho como designer 
Já está definido como um relacionamento que envolve dar e receber. Você 
recebe dinheiro em troca de fornecer designs. Além disso, para que o 
relacionamento não só funcione, mas também floresça, é necessário manter 
seus stakeholders satisfeitos. Essa é mais que uma transação puramente 
econômica. Ela se dá criando laços de confiança, demonstrando sua 
expertise, lidando com as expectativas dos stakeholders, comunicando-se 
com eficácia e (é claro) entregando o que eles esperam. Nessas áreas, 
também é necessário dar e receber. Pense nisso como uma conta bancária: 
toda experiência positiva ao trabalhar com você será um depósito, e toda 
experiência negativa será um saque. Em seu livro The 7 Habits of Highly 
Effective People, Stephen Covey chama isso de “Conta Bancária 
Emocional” 1º Sua meta é manter um saldo positivo junto aos stakeholders 
o tempo todo. 


Sempre que concordar com seu stakeholder, você fará um depósito. Quando 
as métricas melhorarem conforme prometido: um depósito. Quando você 
mostrar um design extremamente bonito, que eles gostem muito: um 
depósito. Porém, quando discordamos, começamos a ver saques. Ao perder 
um prazo ou falhar no follow up de um feedback? Saque. Você se recusa a 
fazer uma mudança porque acredita que sua posição defende melhor o 
interesse do usuário? Você pode estar certo no fim, mas, ao menos 
temporariamente, será um saque na relação de confiança. No fim das contas, 
seu relacionamento com os stakeholders poderá ser avaliado pelo saldo que 


você tiver nessa conta bancária da confiança. A disposição dos stakeholders 
em confiar em você nas ocasiões em que forem mais importantes dependerá 
da presença de um saldo positivo. 


Como designer, isso significa que, às vezes, terá de ceder e permitir que 
seus stakeholders façam alterações, mesmo que você seja contra, talvez 
somente porque precisa fazer um depósito. O importante é que você 
aprenda quais são as batalhas que valem a pena lutar. Você está avaliando o 
quadro geral e escolhendo entrar em um confronto somente nas questões 
que forem mais importantes. Seu foco está em seus objetivos, no problema, 
nos usuários e em garantir que, ainda que haja áreas em que vocês 
discordem, é possível cumprir sua promessa de criar a melhor interface 
possível. Sem dúvida, é uma questão de equilíbrio, e uma situação com a 
qual você estará constantemente aprendendo a lidar. Você sempre deve 
buscar um equilíbrio entre as necessidades do usuário e as necessidades e os 
requisitos de seus stakeholders. Quando essas duas necessidades colidem, 
será necessário tomar decisões difíceis acerca do lugar em que traçará a 
linha. Perceba, porém, que sempre haverá uma opção sobre o local onde 
essa linha será traçada. Em vários aspectos, como designer, você terá de 
desenhar (e redesenhar) essa linha em cada reunião e em cada discussão. O 
resultado do projeto, em sua maior parte, dependerá de sua capacidade de 
administrar essas discussões de modo eficaz e encontrar as melhores 
soluções possíveis, considerando as restrições de trabalhar com pessoas 
reais. 


O objetivo de longo prazo, ao criar laços de confiança com os stakeholders, 
é chegar a um ponto em que a resposta padrão deles seja supor que nossas 
decisões estejam corretas, em vez de serem questionadas desde o princípio. 
Meus clientes sabem que eu tenho opiniões e posso expressar o meu ponto 
de vista. Com o tempo, eles aprendem a confiar em mim e passam de uma 
posição em que supõem que minhas decisões são questionáveis para 
partirem do pressuposto de que elas têm um propósito. Em uma conversa 
telefônica recente, um de meus stakeholders questionou um elemento de 
design, mas, logo em seguida, passou a palavra para mim: “Sei que Tom 
geralmente tem bons motivos para suas escolhas. Tom, por que você fez 
isso dessa maneira?”. Se você conseguir que seus stakeholders abordem seu 
trabalho com essa perspectiva, é sinal de que você está no caminho certo 


para ter sucesso no longo prazo, proporcionando ótimas experiências aos 
usuários, das quais você poderá se orgulhar. 


Quando você está errado 


Um dos segredos de uma boa comunicação é estabelecer laços de confiança 
com as pessoas de cujo apoio você precisa. Não é suficiente apenas ser bom 
em dizer às pessoas que você acredita que está certo, embora isso seja 
importante. Você também deve construir relacionamentos, estabelecer laços 
de confiança e ter um histórico de tomar boas decisões. Quanto mais as 
pessoas virem que seus designs cumprem seus objetivos, mais provável será 
que elas confiem em seu julgamento quando a ocasião se apresentar. Isso se 
consegue somente com a experiência e bons relacionamentos. 


No entanto, algo estranho acontece quando você está errado: há um 
potencial para a quebra dessa confiança. As métricas não melhoram 
conforme você esperava, você deixou de cumprir um prazo visado para o 
lançamento da versão ou foi constatado que seus designs são ineficientes 
para os usuários. É difícil quando expressamos confiança em nossas 
decisões e, então, vemos nossos pressupostos desmoronarem. Espero que 
suas decisões não causem danos graves ao produto, mas, em qualquer 
situação em que seus designs não se mostrem ser a solução correta, haverá 
uma tensão com a qual poderá ser incômodo lidar. Você tem uma escolha: 
assumir suas decisões ou ignorar, negar e isentar-se de qualquer 
responsabilidade. 


Embora estar errado possa dar a impressão de que os laços de confiança 
serão quebrados, na verdade, é uma oportunidade para aumentar o nível de 
confiança se você admitir que cometeu um erro. Parece ser contraintuitivo: 
nós os desapontamos e, agora, devemos admitir nosso erro. Como isso pode 
gerar mais confiança? Em um tribunal de justiça, admitir um crime significa 
que você está pronto para aceitar a punição. Você quebrou a confiança das 
pessoas e agora tem de pagar pelo seu erro. Contudo, no mundo dos 
relacionamentos, as pessoas estão muito mais dispostas a perdoar do que 
você poderia esperar. As pessoas apreciam a honestidade, mais do que as 
aparências falsas. Elas preferem transparência à dissimulação. Sabem que 
podem confiar em você quando veem que você assume seus erros. A 


honestidade é, realmente, a melhor política. Pode ser complicado no início: 
as conversas poderão ser difíceis. Mas, no fim, quase sempre, você sairá por 
cima quando as pessoas perceberem que é uma pessoa confiável — alguém 
que, mesmo que faça besteiras, estará pronto para admiti-las, corrigi-las e 
seguir em frente. 


Em um cenário de pior caso, seu erro custará dinheiro à empresa. É possível 
que você possa perder seu emprego por causa de uma grande estupidez, mas 
não acredito que tenha de temer esse tipo de represália por ser honesto 
sobre o que aconteceu. Como gerente, é realmente desafiador contratar e 
manter bons profissionais. Se você fez um bom trabalho para criar 
relacionamentos e mostrar sua importância na empresa, haverá poucas 
chances de ser demitido porque um de seus designs não atendeu às 
expectativas. Portanto, não tenha medo de seu trabalho, tentando se 
proteger; caso contrário, apenas acabará criando uma profecia que se 
cumprirá sozinha. 


Siga em frente 


O melhor a fazer é apenas tirar o erro do caminho para que todos possam 
seguir em frente. Deixe seu orgulho de lado e parta para a ação a fim de 
remediar a situação. Seja direto e claro acerca do que aconteceu. Você deve 
afirmar claramente: “Eu estava errado” ou “Cometi um erro”, mas também 
deve ser rápido para apresentar a solução e manter o foco na ação, e não nas 
desculpas. Diga aos seus stakeholders o que deve ser feito para corrigir o 
problema e apresente um plano claro para isso. A maioria dos stakeholders 
é orientada a resultados; portanto, admita rapidamente o seu erro e vá direto 
para a solução. Ao fazer com que você seja parte da solução, você também 
se tornará indispensável: eles precisarão de você para ajudar na correção do 
problema. E como a culpa é sua, comunicar um senso de urgência e 
disposição para se esforçar ao máximo na correção do problema ajudará a 
estabelecer os laços de confiança necessários para seguir adiante. 


Os motivos pelos quais algo deu errado não são, nem de longe, tão 
importantes quanto corrigir o problema. Não fique obcecado em recontar a 
história. Em geral, isso soa como desculpas. Em vez disso, descreva 
rapidamente o que aconteceu e vá direto para a correção. Se as pessoas 
quiserem ou precisarem conhecer a história, elas perguntarão e você terá a 


oportunidade de lhes contar. 


O jogo dos culpados 


Também é importante reconhecer que, muitas vezes, as pessoas somente 
querem saber quem deve ser o culpado pelo problema. Pode parecer injusto, 
mas algumas pessoas querem um bode expiatório para que possam falar 
dele com seus chefes caso o assunto venha à tona. Um bom stakeholder 
assumirá o erro com você, na qualidade da pessoa que supervisiona as 
decisões acerca do projeto. Todavia, mesmo que ele não o faça, você 
resolverá a situação com mais agilidade se admitir o que aconteceu e seguir 
em frente. Em geral, assim que a causa do erro é identificada, todos se 
sentem melhor para seguir em frente. 


Jogar-se na própria espada 


Também há situações em que você, como líder, precisará assumir erros que 
talvez não estivessem totalmente sob seu controle, somente para poder 
avançar. As equipes podem ficar muito presas à pergunta: “Por que isso 
aconteceu?”, a ponto de atrapalhar mais ainda o projeto. Embora seja 
improvável que você seja o único responsável por uma falha em um projeto 
que envolva uma equipe toda, ainda assim valerá a pena admitir a sua parte 
(por menor que seja) por levar a equipe ao ponto em que ela se encontra no 
momento. Às vezes, isso pode resultar em você se jogando em sua própria 
espada e recebendo o golpe pela equipe. Nem sempre é aconselhável, mas, 
em situações tensas, nas quais todos fiquem acusando uns aos outros, pode 
ser a melhor maneira de seguir em frente. 


Saber quando você está errado 


A parte mais difícil de admitir que você está errado é, antes de tudo, estar 
ciente de que está errado. É fácil acontecer de sua própria arrogância 
atrapalhar, impedindo que você veja o problema. Como designers, vemos 
nossos designs como nossa criação — essa coisa perfeita que criamos e 
estamos enviando ao mundo. É realmente difícil ver suas falhas, mesmo 
quando as pessoas as apontam para nós. Muitas vezes, negamos o fato de 
que o nosso trabalho não funciona. Como, então, saberemos que estamos 
errados? A seguir, apresentamos três sinais de alerta que estão devidamente 


alinhados com os três itens necessários para você ser um designer de 
sucesso. Como saber se você está errado: 


O problema continua existindo 

Embora estejamos tentando resolver problemas, não é certo que nossos 
designs sempre funcionarão conforme esperado. Se descobrirmos que o 
problema continua existindo, é sinal de que estamos errados e precisamos 
mudar algo. Já vi designers em completa negação, recusando-se a 
acreditar que seus designs fossem os culpados por um problema não 
resolvido. “Refiz o design e está muito melhor agora. Se não houve 
melhoras na conversão, é porque deve haver algum outro problema.” Não 
importa quão bom você ache que sejam os seus designs; se o problema 
continua existindo, é sinal de que você está errado. 


Os usuários não entendem 


Como queremos que nossos designs sejam fáceis de usar, devemos 
garantir que eles realmente facilitarão a vida das pessoas. Caso contrário, 
você está errado! Já trabalhei com designers que estavam tão convencidos 
de que a interface que criaram era fácil de usar que, não importava o 
volume de testes de usuário com falhas, eles não se convenciam do 
contrário. Em geral, culpavam os usuários. “Essa interação é comum nos 
dispositivos móveis atualmente. Se os usuários não sabem usá-la, é 
porque não devem ter familiaridade com padrões de design modernos.” 
Adivinhe só! O usuário não deve ser culpado nesse caso: a culpa é dos 
seus designs. 


Você não tem apoio 
Podemos ser realmente arrogantes quanto à elegância de nossas soluções, 
sobretudo se somos o único designer no projeto. Nós nos sentimos 
justificados dizendo que “ninguém mais sabe o que é um bom design” e, 
desse modo, mesmo diante de opiniões contrárias, insistimos que temos 
razão. No entanto, quando a maioria das pessoas discorda de suas 
decisões, é um sinal certeiro de que você está fazendo errado. “Sei que 
vocês todos discordam dessa decisão, mas, do ponto de vista do design, isso 
faz mais sentido...” Embora nosso desejo seja que todos confiem em nós 
nas decisões difíceis, não é verdade que você estará sempre certo somente 
porque é um designer. Avalie a situação e seja inteligente para perceber o 


modo como as pessoas consideram você ao pressioná-lo a respeito de 
alguma questão. Se você é o dono da empresa, poderá correr esses riscos. 
Contudo, até lá, permita que outras pessoas também influenciem o 
projeto. 


Não importa a situação, ao ver que você está errado e estiver disposto a 
admitir o erro, vá imediatamente para o processo de correção do projeto. 
Mantenha o foco na ação, proponha uma solução, comunique a urgência e 
esteja disposto a agir com rapidez. Sua reação a um erro falará muito sobre 
você como pessoa, e você estará no caminho certo para criar laços de 
confiança com todos de sua equipe a partir desse momento. Reconhecer 
quando você está errado e propor uma solução é um dos modos mais 
importantes de lidar com as mudanças em seu design. 


Administrando as expectativas 


Uma parte importante de seu relacionamento com os clientes, líderes e 
stakeholders é administrar as expectativas que eles têm quanto a você, o 
projeto e os resultados. Sua habilidade para definir, ajustar e comunicar as 
expectativas de modo apropriado é mais importante do que sua capacidade de sempre 
criar a solução perfeita. Isso é particularmente verdadeiro quando você se vê 
fazendo mudanças inesperadas ou conduzindo o projeto a uma direção 
diferente com base no feedback dos stakeholders. Mais do que apenas fazer 
as mudanças que eles querem, você também deve ajudá-los a entender como 
isso será feito, qual é o seu processo de raciocínio e a abordagem, e quando 
eles podem esperar que o trabalho esteja concluído. Definir essas 
expectativas desde o princípio (e durante todo o processo) é importante para 
obter o apoio e a adesão dos stakeholders no longo prazo. 


Menciono essa questão em um capítulo sobre lidar com mudanças porque é 
nos momentos que tentamos corrigir algo errado que mais precisamos que 
todos compreendam a situação. Já vi projetos fracassarem, não porque os 
designers tivessem ideias ruins ou não trabalhassem com afinco para criar 
soluções inovadoras, mas porque não comunicavam as expectativas e, em 
algum momento, perdiam o apoio das pessoas que eram mais relevantes. 


O exemplo de que mais me recordo é o de Jim. Eu o havia contratado para 
liderar o trabalho de design de um novo produto. Como conceito, não 


existia um histórico anterior para esse web service, havia pouco apoio 
interno e, praticamente, nenhum orçamento. Nosso trabalho era criar algo 
do nada, agregando valor a uma área que ainda não havia sido explorada 
antes. Era um território novo e empolgante, mas estávamos diante de uma 
enorme batalha para ajudar outras pessoas a entenderem e darem o seu 
apoio à nossa visão do produto. 


Jim era jovem e inexperiente, mas tinha boas ideias e era um designer 
talentoso. Ele compreendia a visão, tinha experiência relacionada ao 
assunto e muita energia. Também possuía opiniões extremamente fortes, e 
era, até certo ponto, imaturo e muito arrogante. Apesar da advertência de 
meus líderes, eu o contratei. Eu poderia sempre orientá-lo nessas questões, 
pensei. Foi um erro enorme. 


Quando a nova plataforma estava sendo testada, tanto com usuários internos 
como com possíveis clientes, recebemos muitos feedbacks ótimos. Embora 
a maioria das pessoas estivesse interessada, muitas não entendiam a 
necessidade dessa plataforma. Elas estavam dispostas a experimentar, 
porém estavam céticas. Para complicar a situação, havia o fato de que essa 
nova plataforma substituiria o sistema de gerenciamento de conteúdo de 
nosso site. Não só tínhamos o problema de ajudar as pessoas a entenderem 
um novo produto, como também havia muitas pessoas dentro da empresa 
preocupadas com a mudança em seus fluxos de trabalho. 


Jim não usou uma abordagem ideal diante desses desafios. Quando alguém 
expressava preocupações ou fazia perguntas, ele se colocava na defensiva e, 
basicamente, dizia que elas estavam erradas. Em um dos casos, ele disse a 
um gerente que eles não entendiam porque eram velhos. Sua atitude 
consistia em dizer: “Esse produto é mais fácil de usar! Eles não entendem 
isso? O que estamos fazendo é inovador! Eles simplesmente não sabem 
lidar com mudanças”. Como ele era incapaz de resolver essas questões, em 
geral, era considerado como alguém que desprezava os stakeholders. Foi 
um desastre. 


Fiz o melhor que pude para atuar como mentor e orientador. Tínhamos 
conversas frequentes sobre como administrar melhor as expectativas de 
todos. Ele parecia concordar que esse era um problema de comunicação e 
de alinhamento, mas suas ações não pareciam levar isso em consideração na 
prática. Jim apenas queria criar mais funcionalidades e achava que isso 


deixaria as pessoas mais satisfeitas. Seus hábitos de trabalho, 
posteriormente, transformaram-se em um ciclo no qual ele gerava o 
máximo possível de novas funcionalidades e correções. Trabalhava por 
mais horas, mas falava cada vez menos com as pessoas. O problema só 
piorou. 


No fim, tive que demitir Jim. O ambiente havia se tornado esgotante e 
contraproducente ao seu redor. Analisando em retrospectiva, eu jamais 
deveria tê-lo contratado contra a recomendação de meus próprios líderes. 
Eu acreditava (ingenuamente) que o talento de Jim para o design seria 
suficiente para encobrir sua imaturidade, ou que eu poderia preencher as 
lacunas com minha própria habilidade. Eu estava errado e, agora, tinha de 
lidar com as consequências. 


Com a saída de Jim, assumi o projeto pessoalmente, mas eu o via como 
uma questão de administrar as discussões. Comecei imediatamente 
procurando todas as pessoas que estavam irritadas com a atitude de Jim. Eu 
as ouvi, tomei nota de suas sugestões e criei uma lista visível publicamente 
para que todos vissem o que eu estava fazendo. Convidei várias pessoas- 
chaves para diferentes discussões a fim de ajudar a priorizar as necessidades 
em um ambiente de grupo; dessa forma, todos poderiam ver como as 
mudanças de cada um afetariam os outros. Atribuí prioridades e estimativas 
de prazo para cada tarefa. Em alguns casos, quando era apropriado, optei 
por excluir totalmente uma ideia. 


No fim, como resultado, tivemos visibilidade e alinhamento: todos estavam 
na mesma sintonia, todos sabiam para onde estávamos indo e todos 
apoiavam o meu trabalho para fazer acontecer. À medida que as pessoas 
viam que eu estava cumprindo minhas promessas (apesar de ser em um 
ritmo mais lento do que gostaríamos), elas aprenderam a confiar em mim e, 
rapidamente, reconquistei o apoio delas. Quando não conseguia entregar 
algo, eu as informava com antecedência e permitia que elas me ajudassem a 
redefinir as prioridades. Elas tomavam parte nas decisões, tinham 
visibilidade sobre o projeto e se sentiam responsáveis por ele, junto comigo. 


Se, nas semanas anteriores, as pessoas estavam reclamando das mudanças, 
agora elas estavam empolgadas com a direção que o projeto tomava, 
mesmo que fosse demorar muito mais, pois não havia uma pessoa dedicada 
ao projeto em tempo integral no curto prazo. O fato é que entregar mais 


funcionalidades com mais rapidez não era realmente o que as pessoas 
queriam. Elas queriam ter confiança no produto, entender a abordagem e se 
sentirem valorizadas no processo. Elas precisavam de expectativas 
apropriadas. 


Não sei ao certo, mas suspeito que Jim (como muitos outros designers) 
acreditava que seus designs falaram por si mesmos. Acreditava que a 
comunicação interpessoal, como uma habilidade para os designers, era 
totalmente desnecessária porque os nossos designs são, por si só, um meio 
de comunicação. Ele era o especialista, mas sua arrogância turvava sua 
capacidade de valorizar os stakeholders do projeto. Jim era bom em 
resolver problemas e bastante centrado no usuário em seu raciocínio, mas 
não percebeu que, sem o apoio de todos os demais da equipe, ele não 
poderia ter sucesso. Em última instância, Jim perdeu seu emprego porque 
era um péssimo comunicador. Essa é uma lição que todo designer deve 
aprender, embora eu espere que você não precise ser demitido para isso. O 
modo como você se comunica e administra os relacionamentos com os stakeholders é 
essencial para o seu sucesso como designer. 


Acabou, mas somente por enquanto 


À reunião 
Fazer O 


Entender Ouvir Responder follow-up 


e —p————a 


Nossa jornada de reunião e comunicação com os stakeholders terminou, 
mas, apesar disso, é um processo no qual estamos constantemente 
envolvidos. A essa altura, a reunião foi concluída, você já fez um ótimo 
trabalho de fazer o follow up com todos da equipe e está no caminho certo 
para executar aquilo que você vislumbra a fim de proporcionar uma 
experiência incrível aos usuários. Espero que não haja muitas mudanças 
com as quais você esteja preocupado, mas, mesmo se houver, você estará 
bem preparado para encontrar soluções que beneficiarão tanto o usuário 
como os seus clientes. Ao empregar tudo que discutimos juntos, você estará 
preparado para articular (explicar) as decisões de design, comunicar-se com 
os stakeholders, manter a sua sanidade e proporcionar a melhor experiência 
possível aos usuários. 


Antes de encerrar o livro, porém, gostaria de apresentar mais uma 
abordagem que você poderá empregar em sua prática de design, a qual 
ajudará você a ter sucesso na criação de ótimos produtos. O Capítulo 11 é 
um recurso para seus stakeholders, líderes ou clientes. Foi escrito para 
executivos que não são designers e tem como propósito ajudá-los a entender 
o que fazemos e a trabalhar conosco com mais eficiência. 
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Como os executivos podem ajudar os designers 


Há outras pessoas na empresa, além dos designers, que estão interessadas 
em aprender a falar de design. Stakeholders de todos os níveis veem uma 
lacuna na comunicação com a sua própria equipe e procuram recursos para 
ajudá-la a trabalhar conosco e a criar melhores produtos juntos. 


Já tive equipes que me perguntavam: “Como podemos trabalhar juntos de 
modo mais eficaz?” Os executivos me perguntam: “Você pode me ensinar a 
trabalhar com os nossos designers”. Essas pessoas compreendem a 
importância de ter bons relacionamentos no trabalho, e o segredo para 
preservá-los em um setor orientado a tecnologia é manter o foco em uma 
comunicação clara. Com muita frequência, as pessoas se irritam, e os 
projetos se tornam mais difíceis quando duas ou mais pessoas falham em se 
comunicar. As falhas de comunicação resultam em expectativas que não se 
cumprem. Expectativas não atendidas levam a desapontamentos e falta de 
confiança. Queremos evitar que isso aconteça! 


Mesmo quando a comunicação não parece ter restrições, o modo de abordar 
os designers e conversar com eles exerce impacto em sua produtividade, na 
atitude e na criatividade. Mais do que apenas promover uma comunicação 
clara, é preciso ter certeza de que você está obtendo o melhor de seus 
designers. 


Este capítulo é dedicado a ajudar outras pessoas que estão no caminho dos 
designers a entenderem melhor, se comunicar e prosperar nas equipes com 
designers. Não importa se você é desenvolvedor, stakeholder executivo, 
dono de produto, gerente de projeto, profissional de marketing ou trabalha 
na área de defesa do cliente, este capítulo foi escrito para você. Se você é 
designer, arranque e dê estas páginas para o seu chefe ou desenvolvedor 
favorito (ou você pode ler e dar um tapinha em suas costas enquanto 
defendo você e chamo a atenção para as suas peculiaridades suspeitas). O 
objetivo deste capítulo é diminuir a distância entre as pessoas da equipe e 
ajudá-las a serem mais eficazes na comunicação entre si. Queremos que você 


aprenda a obter o melhor de nós. 
Para isso, faremos o seguinte: 


* identificaremos várias áreas essenciais nas quais os stakeholders podem 
nos ajudar a ser mais bem-sucedidos; 


e forneceremos uma lista de dicas para trabalhar com os designers 
regularmente; 


* apresentaremos uma lista de verificação com perguntas necessárias à 
maioria dos projetos a fim de começar o trabalho com o pé direito. 


O reie o cego 


Era uma vez um rei que tinha um cego como conselheiro. Quando voltava 
de uma caçada com uma grande comitiva, o rei ficou com muita sede e viu 
uma plantação de melancias. Ele chamou seus servos e pediu que pegassem 
algumas para matar a sua sede, porém o cego começou a rir. 


“Por que você está rindo?” — perguntou o rei. 
“Meu bom rei, não há nenhuma melancia por aqui!” — ele respondeu. 


O rei ficou surpreso. “Você é cego! Como sabe que não há melancias por aqui? 
Posso vê-las com meus próprios olhos. Você não!” 


E o cego respondeu: “Meu senhor, uma pessoa não precisa enxergar para saber 

essas coisas. Não estamos mais na época de melancias. Talvez haja algumas 

apodrecendo nos campos, mas todas as frutas boas já foram colhidas”. 
Note que o rei viu melancias, e era isso que ele queria, mas o cego era mais 
esperto. Parecia Óbvio para o rei que essa seria a solução para a sua sede. 
Também era muito improvável que o cego pudesse entender a situação o 
bastante para ajudar o rei com o seu problema. Apesar disso, a perspectiva 
do cego permitiu que ele ajudasse o rei e, em última instância, poupou o rei 
de colher melancias estragadas. Suponho que haja destinos piores! 


Obviamente, essa é uma história para divertir, mas eis o ponto principal: há 
pessoas em sua equipe que permitirão que você tenha sucesso, ajudarão 
você a fazer um trabalho melhor e apresentarão um ponto de vista que você 
não tem. Talvez haja ocasiões em que pareça que os designers não sabem do 
que estão falando, ou que não poderiam, possivelmente, contribuir com 
soluções relevantes para problemas difíceis, mas isso não é verdade. Os 


designers são solucionadores de problemas, seja para resolver questões 
ligadas a negócios ou para propor soluções de programação. Já vi muitas 
pessoas olharem admiradas para os designers quando eles fizeram sugestões 
que todos os demais achavam que estavam além de sua esfera de 
compreensão. Assim, para aproveitar ao máximo o seu tempo com os 
designers, você deve se lembrar dos quatro pontos a seguir: 


* perceber que temos expertise nessa área; 

* priorizar nossas necessidades para que possamos trabalhar; 

e dar autonomia à equipe toda para que ela possa avançar rapidamente; 
* reconhecer que, nós também, somos seres humanos. 


Perceber que temos expertise nessa área 


Um dos principais desafios que nós, designers, enfrentamos é fazer com que 
outras pessoas confiem em nós, acreditem que somos realmente bons no 
que fazemos e tomamos boas decisões. O estranho é que muitas dessas 
mesmas pessoas também elogiarão o nosso trabalho se gostarem dele. No 
entanto, quando as pessoas discordam de nossas decisões de design ou as 
questionam, pode haver muita desconfiança — ou, no mínimo, não haverá 
uma confiança total. Muitas pessoas veem os designers como alguém cuja 
função é meramente criar uma aparência bonita e, em geral, não lhes é 
concedida a oportunidade de ter um lugar à mesa quando se trata da tomada 
de decisões. 


À medida que trabalhar com os designers durante a sua vida, perceberá que 
eles têm expertise na área de design e o trabalho deles é mais do que apenas 
deixar o seu projeto com uma aparência bonita. Eles estão preparados para 
encontrar soluções de design para problemas de negócios. Você os 
contratou e os têm em sua equipe por um motivo: eles são especialistas em 
design e melhores nisso do que você. Os designers têm expertise para 
entender o que facilitará a vida dos usuários. São treinados nas técnicas e 
melhores práticas de usabilidade. Conhecem os padrões e elementos de 
design apropriados. Você deve confiar neles para que façam o trabalho, sem 
lhes dizer como devem fazê-lo. 


Na verdade, fazer design é realmente difícil. Parece simples e fácil porque 
você vê apenas o resultado. Há muitas tarefas envolvidas no processo de 


design: definir casos de uso, mapear fluxos, escrever os requisitos, além de 
muito trabalho de concepção e iteração em wireframes e protótipos. Você 
não vê tudo que jogamos fora, não percebe o tempo que gastamos nem vê a 
nossa angústia para encontrar as soluções adequadas. Quando nossos 
designs chegam até você, já trabalhamos com afinco, verificando todos os 
diferentes ângulos da situação. Há muito mais no design do que somente 
colocar alguns elementos em uma página. 


Se estamos indo até você com a nossa proposta, você poderá partir do 
pressuposto de que acreditamos que essa é a melhor solução. Você não 
precisa nos perguntar se gostamos dela ou não: nós gostamos! Nós a 
criamos! Se você discordar, sem dúvida, será apropriado nos envolver nessa 
discussão, mas não comece com uma postura cética questionando se 
sabemos o que estamos fazendo. Em vez disso, entenda o nosso processo de 
design, procure compreender o nosso ponto de vista e faça várias perguntas 
para ter certeza de que estamos na mesma sintonia. 


Além do mais, como o design pode ser complexo e muitos elementos 
podem estar inter-relacionados, saiba que qualquer mudança que você 
sugerir afetará o resto do projeto. Há um efeito em cascata que poderá 
exigir de nós um retrabalho em outras partes. Não é uma mudança isolada. 
Muitos stakeholders fazem sugestões bem-intencionadas, esperando que as 
mudanças sejam simples ou exijam somente alguns minutos. Não é 
incomum ouvir o seguinte: “Tudo que você precisa fazer é mover isso para 
lá, certo”. Contudo, o processo de atualizar uma parte do design exige que 
demos um passo para trás e avaliemos nossas decisões. Mover um item 
pode exigir o deslocamento de outro também. Às vezes, a mudança nos 
elementos pode causar problemas no fluxo da aplicação. Nem sempre, mas 
ocorre com frequência. 


Portanto, você deve estar ciente de que suas sugestões podem ser mais do 
que parecem ser e talvez não sejam tão simples quanto parecem. Mesmo 
alterações simples exigirão certo volume de retrabalho. Eu sugeriria 
primeiro perguntar sobre o impacto das mudanças que você estiver 
sugerindo. Procure entender como as suas recomendações afetarão a equipe 
antes de insistir que as mudanças sejam feitas. Estar alinhado quanto ao 
trabalho envolvido é uma parte importante da discussão. 


Priorizar nossas necessidades para que possamos ter sucesso 


De longe, o maior obstáculo para qualquer projeto é deixar de dar tudo o 
que os designers precisam para que façam o seu trabalho. Quando você nos 
pede para fazer o design de algo, precisamos que você tome várias atitudes 
para podermos fazer o trabalho com eficiência. 


Isso vai muito além de expressar o que você vislumbra para o projeto e nos 
deixar correr soltos. Precisamos que os requisitos de negócios estejam 
documentados, e os cronogramas definidos. As necessidades técnicas 
também são essenciais: acesso aos servidores, aprovação de contratos ou 
compartilhamento de suas análises de dados e dos dados. Muitas vezes, 
precisamos da permissão de outras pessoas da empresa e de acesso a elas: 
gatekeepers,l especialistas no domínio e profissionais que trabalham em 
defesa dos clientes. Não poderemos trabalhar, a menos que você 
proporcione esses recursos a nós; portanto, correr atrás do que precisamos 
tem de ser uma prioridade. Deixe que ajudemos você a ter sucesso nos 
equipando com o que for necessário para fazer o nosso trabalho. Faça o que 
for preciso para agilizar tudo, de modo que possamos dar início ao trabalho 
imediatamente. 


Isso significa que você deve dar prioridade às nossas necessidades a fim de 
que possamos fazer o nosso trabalho. Você deve estar preparado para 
participar de nossa reunião. Revise os designs que enviamos com 
antecedência para saber qual é o feedback que você nos dará. Não há nada 
pior do que alguém comparecer à reunião dizendo que não teve tempo de 
revisar o nosso trabalho antes e então expressar uma série de reações 
automáticas ao ver o nosso trabalho pela primeira vez. Não, precisamos que 
você seja melhor que isso. Valorize o nosso tempo do mesmo modo que 
valorizamos o seu, estando preparado. 


Você já deve vir com uma lista de perguntas ou preocupações anotadas. 
Poderá até mesmo encontrar algum material de referência, como outras 
aplicações ou dados de um projeto diferente que nos ajudem a entender o 
seu ponto de vista, para que possamos entregar aquilo de que você precisa. 
Acima de tudo, faça isso em um tempo razoável. Se demorar demais para 
analisar o nosso trabalho e dar uma resposta, talvez tenhamos menos tempo 
disponível para implementar suas mudanças. Perdemos tempo esperando 


por você e então nos apressam para que o trabalho seja feito. Você não 
conseguirá que façamos o nosso melhor trabalho nesse cenário. Por favor, 
valorize nossa função em sua equipe dando prioridade às nossas 
necessidades para que possamos ser bem-sucedidos. 


Testes de usabilidade e pesquisas 


Um recurso de que, com frequência, precisamos, mas não conseguimos ter, 
é a permissão e o orçamento para fazer testes de usabilidade. Precisamos 
testar seu projeto com outras pessoas a fim de verificar se funcionará 
conforme esperado. Esse não é um grupo focal, não estamos perguntando 
aos usuários o que eles querem. O teste consiste em ter tempo para observar 
as pessoas usarem o nosso site ou aplicação e, em seguida, tomar notas 
sobre as maneiras como podemos melhorar a experiência dos usuários. É 
um teste que se baseia em tarefas e é, principalmente, de observação. Não 
fazemos isso o suficiente porque, muitas vezes, não temos permissão para 
gastar nosso tempo com essa tarefa. Não é um teste caro, e o resultado mais 
do que compensará, pois revelará os problemas mais cedo ou permitirá 
otimizar as tarefas para ter uma aplicação melhor. Dê permissão e o 
orçamento para fazer testes de usabilidade, e até mesmo nos incentive a 
fazer mais testes desse tipo. 


Dar autonomia à equipe toda para que ela possa avançar 
rapidamente 


Os projetos se tornam estagnados ou avançam lentamente quando as 
decisões não são tomadas com rapidez. O melhor que você pode fazer pelo 
projeto é tomar decisões rápidas, ser fiel a essas decisões e dar autonomia a 
outras pessoas para que tomem as decisões em seu lugar. Isso permitirá que 
a equipe toda trabalhe rapidamente e entregue o melhor produto possível, 
com uma ótima experiência para os usuários. Não me canso de enfatizar 
esse ponto. A principal diferença entre uma startup audaciosa e um monstro 
burocrático é a rapidez com que eles tomam decisões e avançam. Há pouca 
relação com talentos, recursos ou ideias, mas tem tudo a ver com a 
agilidade da equipe. Os projetos falham ou definham quando os líderes não 
tomam decisões ou não permanecem fiéis às decisões que tomaram. Você 
tem total controle sobre isso. 


Você pode fazer com que tenhamos sucesso ao ser decisivo: tome decisões, 
seja fiel a elas e siga em frente. Ser indeciso ou adiar uma decisão realmente 
custará tempo e dinheiro. Esperaremos ociosamente que você tome uma 
decisão, ou trabalharemos e retrabalharemos nossos designs a fim de 
acomodar as mudanças. Pode parecer que esperar alguns dias até a próxima 
reunião seja bastante apropriado, mas, nesses poucos dias, já poderíamos 
estar trabalhando na próxima atividade ou encontrando as falhas em nosso 
raciocínio atual. Os melhores projetos em que trabalhei foram aqueles em 
que nos reuníamos diariamente com os stakeholders. É isso mesmo: todos os 
dias. Eu passava o dia fazendo o design, mostrava o meu trabalho para o 
cliente de tarde, recebia um feedback imediato e, então, fazia tudo de novo. 
Esse tipo de ritmo nos faz sentir que temos autonomia e nos mantém 
empolgados. Às vezes, proponho revisões diárias de design com grandes 
clientes, e eles reclamam. Por quê? Porque eles já têm reuniões de mais e 
parecem não conseguir compreender um processo que itere e progrida tão 
rapidamente. Apesar disso, são esses projetos que sempre demoram mais e 
proporcionam resultados inferiores. Quando os stakeholders se envolvem 
apenas uma vez por semana (ou menos!), posso adiantar que quase o dobro 
do tempo será necessário. 


Quanto melhor você for em tomar decisões boas e rápidas, melhor será para 
nós. Não só seremos mais produtivos, como também estaremos mais felizes 
e satisfeitos com o nosso trabalho. Nós nos sentimos bem com o que 
fazemos quando sabemos que o trabalho está avançando. É melhor fazer 
algo (mesmo que esteja errado) e manter o projeto em andamento que não 
fazer nada e permanecer na ambiguidade. A indecisão e a mudança nas 
decisões acabam com um processo eficiente de design; portanto, dê 
autonomia aos seus designers e a toda a equipe para que avancem o mais 
rápido possível. Prometo que qualquer que seja seu risco no processo de 
lhes dar poder para tomar decisões compensará no que diz respeito ao 
moral, à agilidade e à energia. 


Dando autonomia à equipe 


Uma das melhores maneiras de manter seu projeto avançando rapidamente 
é nos dar autonomia (a nós, os designers!) para tomar decisões, concedendo 
um volume razoável de autoridade a nós. Deixe que tomemos algumas das 


decisões. Quando não estiver certo sobre o que fazer, permita que os 
designers colaborem com a decisão. Confie em nós quando fizermos uma 
boa argumentação em defesa de nossas decisões, mesmo que você discorde. 
Pergunte o que faríamos e, então, deixe que tomemos a decisão final. Esse 
nível de autonomia resultará em um produto melhor, equipes mais 
satisfeitas e um progresso rápido. 


Reconheço que nem toda decisão sobre o produto pode ser confiada aos 
designers. Há outros fatores, considerações sobre os negócios e até mesmo 
outras pessoas ou equipes envolvidas. No entanto, muitas vezes, essas 
outras considerações turvam o seu próprio julgamento e impedem que você 
veja que a solução mais simples e óbvia é realmente a melhor. De acordo 
com a minha experiência, as recomendações de um designer muitas vezes 
acabam por ser a solução à qual, em algum momento, chegaremos, de 
qualquer forma. Já trabalhei com grandes clientes nos quais as várias 
reuniões com as equipes e os executivos tornavam o processo lento, às 
vezes causando atrasos da ordem de semanas. Podemos brincar com 
algumas ideias, talvez até mesmo implementar aquela da qual o VP tenha 
gostado mais, somente para, mais tarde, ter de retrabalhar o design (meses 
depois) a fim de acomodar a nossa recomendação original. O que pode 
parecer ser uma ótima ideia em uma reunião nem sempre é a que melhor 
funciona na prática. Nem sempre acontece, mas ocorre com uma frequência 
suficiente para ser um desperdício de tempo digno de nota. 


Um dos sites mais gratificantes que criei foi um no qual convenci meu chefe 
a deixar que eu mantivesse o foco exclusivamente nesse projeto único e 
tomasse as decisões finais. Era arriscado. Outros stakeholders na empresa 
estavam preocupados com a possibilidade de que eu não conhecesse 
suficientemente suas áreas. As pessoas estavam preocupadas, achando que 
eu faria besteira. Eu estava nessa empresa havia muitos anos e sabia quais 
eram várias de suas necessidades, mas não conhecia todas. No entanto, foi 
suficiente para que eu criasse a próxima versão do site, ainda que não fosse 
perfeita. Depois de três meses, apresentei um produto acabado que era 
significativamente melhor do que o site existente. 


Todos os stakeholders ficaram satisfeitos com o que eu havia feito? Não, 
mas alguns ficaram. O site resolveu todos os problemas que tínhamos”? Até 
certo ponto. Porém, isso não nos impediu de colocá-lo no ambiente de 


produção e, então, iterar logo em seguida a fim de aperfeiçoá-lo. 
Conseguimos oferecer uma melhor experiência online com muita rapidez e, 
em seguida, expandimos a autonomia para a tomada de decisões na versão 
seguinte. Veja que, se houvesse muitas pessoas tomando decisões e me 
dizendo o que eu deveria fazer, o site poderia ter demorado um ano ou mais 
para ser criado. Em vez disso, optamos por valorizar a tomada rápida de 
decisões. Recusamos o perfeito como o inimigo do bom. Esse tipo de 
confiança e autonomia é raro, mas seria difícil encontrar um modo mais 
rápido para fazer o trabalho. 


Meu desafio a você é permitir, de forma deliberada, que seus designers 
tenham a liberdade para tomar as decisões de design. Comece com algumas 
decisões de baixo risco, mas, rapidamente, avance em direção à visão geral 
e mais ampla do produto. Comece concordando com eles com a maior 
frequência possível até sentir que pode deixar que os designers tomem as 
decisões por conta própria. Descubra o nível no qual você começa a se 
sentir desconfortável em ceder o controle e então passe somente um pouco 
desse ponto. Acredito que o ponto ideal para dar um bom poder de 
autonomia na tomada de decisões está um pouco além de sua zona de 
conforto. Os líderes devem sempre se sentir um pouco desconfortáveis ao 
passar as decisões para a sua equipe. 


Reconhecer que, nós também, somos seres humanos 


Um ingrediente importante, que falta nos relacionamentos entre 
stakeholders e designers, é reconhecer que somos todos seres humanos. 
Precisamos lembrar que as pessoas com quem trabalhamos são seres 
humanos. Devemos manter o foco no relacionamento e na comunicação. 
Acima de tudo, porém, devemos ser gentis, utilizar uma linguagem 
conveniente e gerar uma discussão que dê resultados positivos. 


Isso pode parecer óbvio, mas os designers também são seres humanos. Na 
cultura de negócios, os projetos e os prazos de entrega muitas vezes são 
mais valorizados (involuntariamente) do que as pessoas que entregam esses 
projetos ou cumprem esses prazos. Lembrar que sua equipe é composta de 
pessoas com vidas, famílias e interesses que vão além da sala de reuniões é 
importante em qualquer empresa, e não é diferente no caso dos designers. 
Todos nós temos personalidades diferentes, ideias originais e perspectivas 


únicas sobre a vida. Há outros acontecimentos nas vidas das pessoas, além 
desse projeto. Alguém está cuidando de uma mãe enferma, outra pessoa 
precisa buscar os filhos na escola e levá-los a um jogo, enquanto outra irá 
para casa sozinha. Essa abordagem de liderança centrada nos seres humanos 
nada mais é do que lembrar e reconhecer que as pessoas com quem você 
interage são reais. Elas têm sentimentos, podem ser desenvolvidas e 
estimuladas, ou podem ser destruídas e descartadas. Você pode ignorá-las 
ou pode mostrar interesse por elas. Como podemos imaginar, você terá os 
melhores resultados ao abordar as pessoas com uma mentalidade que 
reconheça o que há de humano nelas. Assim, com a frequência que for 
necessária, pare, observe as pessoas na sala e lembre-se disto: elas são seres 
humanos. 


Depois que fizer isso, o próximo passo é manter o foco na construção de 
bons relacionamentos. Embora seja importante reconhecer que nossas 
funções específicas como designers moldam a nossa identidade, a base para 
uma boa comunicação é um bom relacionamento. Não há empresa, 
gerenciamento nem concessão de autonomia que compense uma falta de 
conexão pessoal no relacionamento. Com muita frequência, as reuniões 
dizem respeito a projetos, os projetos dizem respeito a tarefas, e as tarefas 
são tediosas e impessoais. O resultado é uma abordagem mecânica para os 
projetos, sem substância, empolgação ou vida. Assim, além de ser 
organizado e fazer dos projetos uma prioridade, também é necessário 
trabalhar arduamente para estabelecer uma conexão que falará mais por 
você do que as palavras que saírem de sua boca. Seja gentil e se disponha a 
nos conhecer. Mostre um interesse genuíno por nós fazendo perguntas sobre 
nossos hobbies, bichos de estimação ou o time favorito. Você não precisa de 
pufes nem de mesas de pebolim em seu escritório, mas deve ser gentil e se 
mostrar interessado nas pessoas. Não é preciso muito para mostrar que você 
realmente se importa com as pessoas com quem trabalha. 


Utilize uma linguagem conveniente 


Reconhecer que somos todos seres humanos, então, nos leva naturalmente a 
uma situação em que estaremos mais bem preparados para empregar estilos 
de linguagem e de comunicação que sejam mais convenientes para discutir 
o design. Ao dar feedbacks para os nossos designs, mantenha o foco nos 


designs propriamente ditos, e não no designer que os criou. Não seja rude 
nem ataque o nosso trabalho. Em vez disso, faça muitas perguntas, em um 
esforço para compreender o nosso ponto de vista e a abordagem. Seja 
direto, porém gentil. Concentre-se nos problemas e nas possíveis soluções, 
e não nas pessoas e em suas decisões. O design já é um assunto difícil para 
discutir, pois as pessoas (designers) podem acabar se envolvendo demais 
com seus trabalhos. Ao criticar as pessoas por causa de suas decisões, você 
as deixará encurraladas e fará com que assumam uma postura defensiva. O 
design, mais do que várias outras áreas, tem uma propensão para causar 
divisões e polarizações. Reconheça isso desde o princípio e se esforce para 
usar palavras que ajudem na discussão, em vez de colocar as pessoas umas 
contra as outras. O modo como você decide falar com os designers sobre o 
trabalho deles terá um efeito drástico em sua capacidade de serem 
agradáveis e produtivos para você. 


Além disso, tenha paciência quando houver mudanças. Nem sempre 
sabemos como nossos designs funcionarão na realidade; portanto, é natural 
que precisemos modificar o nosso trabalho, mesmo depois que estiver no 
ambiente de produção. É comum acreditar que fizemos todas as escolhas 
certas em nossos designs, mas, quando os testamos com os usuários pela 
primeira vez, percebemos que fizemos suposições incorretas. Esses tipos de 
desafio fazem parte do processo. Com efeito, sempre me sinto um pouco 
constrangido e acanhado quando preciso voltar aos desenvolvedores e pedir 
que façam uma mudança. Apesar de isso fazer parte do processo de design, 
estou admitindo meus erros e assumindo a culpa por algo que causei. Por 
ser minha culpa, talvez seja difícil assumi-la, mas isso será necessário para 
que se possa promover uma ótima experiência aos usuários. Você deve 
esperar que encaremos esses desafios inesperados e até mesmo nos 
incentivar a fazer isso, e nos ajudar a preparar o resto da equipe para as 
mudanças. Dê o seu apoio o máximo possível durante essas mudanças e 
abra o caminho para que os designers se sintam bem ao fazer o que é certo 
para o usuário e para o produto. 


Dez dicas para trabalhar com designers 


Para resumir rapidamente, aqui estão dez dicas rápidas para ajudar você a 
trabalhar com os designers com mais eficácia: 


1. Mantenha o foco no que funciona. Elimine a palavra “gosto” de seu 
vocabulário e sempre fale sobre o que funciona ou o que não funciona. 
Suas preferências pessoais são menos importantes que as necessidades 
do usuário ou dos negócios. 


2. Não forneça soluções. Fale-nos sobre o problema que você vê e descreva 
o que deve ser resolvido, mas não nos diga o que devemos mudar 
primeiro. Deixe que encontremos a solução. 


3. Faça muitas perguntas. Esse é o segredo para que você veja a partir do 
nosso ponto de vista e compreenda nossos motivos. Faça perguntas para 
entender o nosso processo de raciocínio. 


4. Não alegue ser o usuário. A verdade é que cada usuário é diferente e você 
não representa o mercado-alvo mais do que o designer. Alegar ser o 
usuário de sua aplicação ou site não agrega valor à discussão. 


5. Deixe que expliquemos nossas decisões. Não apresente o seu próprio ponto 
de vista e vá embora. Dê tempo e espaço para que possamos formular 
uma resposta apropriada. 


6. Dê autonomia para que possamos tomar decisões. Mesmo que você 
discorde de nossa decisão, aprenda a confiar em nós nas áreas em que 
temos expertise e, então, deixe que nos responsabilizemos pelos 
resultados. 


7. Utilize uma linguagem conveniente. Pode ser difícil receber feedback sem 
permanecer um pouco na defensiva. Evite uma linguagem desagradável 
ou cheia de excessos e mantenha o foco de seu feedback nos designs, e 
não nos designers. 


8. Pergunte se há dados. Todos nós deveríamos usar dados para apoiar 
nossas decisões, mas, somente porque o designer não tem dados, não 
significa que ele está errado. 


9. Esteja preparado. Revise nosso trabalho com antecedência e tenha uma 
lista de perguntas ou preocupações pronta. Não espere, deixando para 
expressar reações automáticas no momento da reunião. Seu feedback 
deve ter um propósito e deve ter sido cuidadosamente considerado. 


10. Dê o que precisamos para sermos bem-sucedidos. Sejam logins, acesso à 
análise de dados ou permissão para fazer testes de usabilidade, 
precisamos que você nos dê recursos para trabalhar de modo eficaz. 


Faça disso uma prioridade. 


Lista de verificação para projetos de design 


Para ajudar todos a estar mais bem preparados, apresentamos, a seguir, uma 
lista de verificação contendo as necessidades mais comuns no design web e 
no design de produtos. Se todos os stakeholders cuidarem disso no início, 
os projetos avançarão com mais rapidez e sempre proporcionaremos uma 
experiência de melhor qualidade aos usuários. Eu utilizo essa lista com 
meus próprios clientes a fim de garantir que temos tudo aquilo de que 
precisamos no início de cada projeto. Empregar uma lista de verificação 
como essa garante que todos estejam sincronizados e facilita bastante a 
comunicação contínua acerca do projeto. Ela define uma boa base para falar 
das decisões de design a partir desse momento. 


A lista é apenas uma ferramenta e deve ser usada com um grau de 
flexibilidade apropriado ao projeto, à empresa ou à equipe. Alguns desses 
itens não são necessários em todos os projetos; outros projetos podem ter 
necessidades adicionais e, durante a vida de um projeto, esses itens podem 
mudar naturalmente, à medida que a equipe adquire um ritmo. Use a lista a 
seguir como um guia, mas não tenha medo de alterá-la (ou alterar as suas 
respostas) à medida que o projeto avançar. 


Visão e objetivos da gerência 


R Qual é o propósito do produto, do site ou da aplicação? Defina o 
principal uso ou necessidade. Por que ele existe? 

R Qual é a visão geral para o produto, o site ou a aplicação? Uma visão 
bem definida nos ajuda a entender como esse projeto afetará os planos 
para o futuro. 

R Quais são os objetivos de curto prazo para os negócios como um todo? 
O que a empresa quer realizar e como esse projeto se enquadra nesses 
objetivos? 

R Qual métrica podemos monitorar? Como saberemos que fomos bem- 
sucedidos? Precisamos ter um modo de avaliar o nosso sucesso. 

R Qual é a estratégia para alcançar o objetivo? Isso corresponde a o que 
precisa ser feito para alcançar o objetivo: as tarefas, as táticas ou os 


artefatos a serem entregues para o projeto. 


R Quais são os requisitos de negócios para esse projeto? Ter requisitos 
documentados desde o início é importante, mas também podemos 
trabalhar juntos para defini-los. 


Usuários ou clientes 


R Quem são os usuários? O que sabemos sobre eles? Esse pode ser um 
ponto de partida para descrever personas e escrever histórias de 
usuários. 


R Qual é o principal problema que queremos resolver para eles? Quais são 
as principais dificuldades para os usuários no momento”? Esse talvez não 
seja o objetivo do projeto no momento. 


R Como os usuários interagem com o site ou a aplicação? Qual é o 
contexto/local, o tipo e o tamanho dos dispositivos, os pontos de entrada 
e de saída ou a frequência do engajamento? 


R Qual é o plano ou o orçamento para testes de usabilidade e/ou 
entrevistas com usuários? Precisamos trabalhar com usuários reais para 
fazer um design para eles. 


Fluxo de trabalho e comunicação 


R Quais ferramentas devemos usar para nos comunicar? Qual é a melhor 
maneira de obter respostas? Todos têm preferências diferentes para 
email, texto, vídeo e telefone. 


R Como deve ser o nosso ciclo de reuniões? Queremos atualizações 
rápidas e frequentes, bem como relatórios mais extensos e detalhados 
sobre o progresso. Por exemplo, 30 minutos diariamente, mais uma 
revisão de design semanal com uma hora de duração (ou mais). 


R Qual é o cronograma para o projeto? Com que frequência podemos 
lançar versões? Defina um padrão para quando as tarefas devem ser 
concluídas. Considere o prazo de entrega e trabalhe de trás para a frente 
no calendário. Isso pode dar uma base para definir os recursos ou o 
escopo também. 


R Quem tem a palavra final nas decisões? Identifique uma pessoa de modo 
geral e/ou atribua um indivíduo para cada função: Negócios, Produto, 


Design, Engenharia ou Conteúdo. Sem comitês. 


Acesso às informações e às pessoas 


R Quais recursos técnicos serão necessários? Quem pode dar acesso a 
nós? Isso inclui credenciais de login, contas de email, VPN ou acesso 
aos servidores. 


R Que dados existentes estão disponíveis? Acesso a análises de dados, 
estudos de usabilidade, testes A/B ou quaisquer relatórios de negócios 
ou conjuntos de slides. 


R Há algum site ou aplicação existente que podemos usar como 
referência? Há outro produto que possamos usar como base para esse 
projeto? 

R Como é o organograma da empresa? Quais pessoas são importantes em 
nosso projeto? Uma lista de pessoas relevantes, incluindo nomes, 
cargos, relacionamentos e áreas de expertise, com informações para 
contato. 


R Temos permissão para trabalhar com essas pessoas? Apresentações 
necessárias devem ser feitas ou permissões devem ser concedidas a nós 
para entrar em contato com outras pessoas da empresa. 


Requisitos técnicos e de design 


R Quais são as diretrizes de design que já existem? Diretrizes para gestão 
da marca, padrões de logo, documentação da linguagem do design, guias 
de estilo ou bibliotecas visuais de UI. 


R Qual é o tom ou o estilo do design? Isso pode estar definido nas 
diretrizes de design. Se não estiver, podemos discuti-los. 


R Quais são as nossas regras básicas para o design ou os objetivos que o 
orientam? Uma lista resumida das limitações, das melhores práticas ou 
das prioridades nas quais devemos manter o foco para orientar as 
decisões de design. 


R Que outros sites ou aplicações são semelhantes ou relevantes? Uma lista 
dos concorrentes e de produtos parecidos ou dissociados que sejam 
interessantes. 


R Quais requisitos técnicos influenciarão o design? Acessibilidade, versão 


do navegador/sistema operacional, suporte para dispositivos ou 
tamanhos da janela de exibição, responsivo/adaptativo/móvel. 


Faça o download dessa lista de verificação acessando 
http://tomgreever.com/resources . 


Um lugar à mesa 


O modo como as empresas abordam o design tem mudado drasticamente. O 
design costumava ser algo que apenas fazia a empresa parecer profissional 
ou projetava uma imagem para o produto ou a marca. Atualmente, o design 
é usado para resolver problemas reais dos negócios, e cada vez mais 
empresas estão percebendo essa importância. Empresas inteiras estão se 
movendo para fazer com que o design seja o centro de seus processos 
porque reconhecem que isso é bom para o objetivo geral da empresa. Os 
produtos mais famosos e populares hoje em dia são aqueles que têm um 
bom design e proporcionam uma experiência de qualidade superior aos 
usuários. 


Para atender a essa demanda, muitas empresas estão contratando designers, 
montando equipes e modificando seus processos para valorizar o design de 
modo mais evidente; apesar disso, muitas dessas mesmas empresas ainda 
deixam a desejar quando se trata de entregar um produto. Inicialmente, 
pode parecer que seus designers não sejam suficientemente talentosos, ou 
que há um descompasso entre as necessidades dos clientes e a equipe de 
design. É isso que leva os gerentes e os desenvolvedores a procurarem 
recursos (como este livro) para aprender a falar melhor sobre o design ou 
melhorar a sua comunicação e os relacionamentos profissionais com os 
designers. Escrevi este capítulo porque a dificuldade de trabalhar com os 
designers é um problema real, e qualquer stakeholder poderá se beneficiar 
se entender seus designers. Contudo, quando se trata de uma prática geral 
de negócios, há um problema subjacente. Uma melhor comunicação 
ajudará, mas esse não é o problema principal. 


As empresas com dificuldade para incorporar uma mentalidade de design 
têm um problema: não há designers no nível dos executivos. O problema de 
entregar produtos com designs ruins não é uma questão de talento, mas de 
liderança no design. Essas empresas não têm uma visão que inclua a 


experiência dos usuários. Elas têm designers talentosos, mas não há pessoas 
que tomem decisões com uma mentalidade voltada para o design. As 
empresas que falham consistentemente em entregar os produtos que 
acreditam que deveriam oferecer precisam de mais um lugar à mesa: o lugar 
do designer. 


Pense nos produtos, sites ou aplicações mais populares, com os quais você 
tem familiaridade. Quem iniciou a empresa? Quem é o CEO? Na maioria 
dos casos, as pessoas que estão à frente das empresas que criam grandes 
produtos são pessoas com uma mentalidade centrada no design, mesmo que 
não sejam tecnicamente qualificadas como designers. Elas são designers por 
direito próprio, mas também se cercam de outras pessoas que são designers 
talentosos. 


Essas empresas não precisam “se virar” para fazer com que o design seja o 


centro de sua cultura porque o design já é valorizado ao máximo. Elas 
simplesmente são empresas que valorizam o design. 


Se você leva a sério o desejo de que sua empresa, produto ou serviço sejam 
conhecidos por uma ótima UX, coloque um designer no nível executivo. Já 
não é mais adequado contratar um freelancer por intermédio de um gerente 
de vendas para criar o seu site. Você não pode simplesmente convidar os 
designers para uma reunião, inspirá-los com a sua visão e, então, esperar 
que eles tragam o melhor produto de todos os tempos até você. Você vai 
fracassar se o único designer de sua empresa estiver sentado em uma mesa 
junto ao pessoal de marketing, no fim do corredor. É necessário que os 
designers estejam envolvidos nos níveis mais altos da empresa se você 
espera ter sucesso em um mercado orientado ao design. Eles devem ter 
poder para tomar decisões difíceis, precisam de autonomia para criar o 
melhor produto possível e da confiança e do apoio de outros executivos. 


Como isso pode ser feito? Em um mundo ideal, você teria a autonomia, o 
dinheiro e o tempo necessários para criar uma estrutura organizacional que 
refletisse esses valores. Crie um cargo de diretor geral de design ou de vice- 
presidente de design. Envolva-os em todos os detalhes, deixe que eles 
decidam sobre o direcionamento do produto ou do design e dê a eles uma 
equipe. Infelizmente, isso não é algo que qualquer empresa possa fazer 
facilmente. Falando de modo mais prático, os designers e os executivos 
precisam de um nível mais profundo de envolvimento e de confiança. As 


pessoas que fazem o design de produtos, sites ou aplicações precisam se 
reunir com o CEO. Elas precisam se comunicar frequentemente com outros 
executivos. Isso pode ser apenas uma questão de proximidade: dê a elas 
uma mesa na área dos executivos ou nas proximidades. É incrível como o 
design e a comunicação são facilitados quando um VP passa 
ocasionalmente pela sua mesa para dizer oi. É o que chamamos de 
“cerenciamento andando por aí” (management by walking around — termo 
atribuído à Hewlett-Packard2 e descrito no livro Search of Excellence). 


Um dos melhores (e mais simples) modelos que já vi é o de um ex- 
empregador que havia deslocado o diretor de criação para uma mesa, junto 
a outros executivos, em um ambiente de escritório aberto. Apenas o fato de 
estarem sentados próximos uns dos outros melhorou bastante a sua forma 
de pensar, fez uma afirmação política sobre seus valores e definiu 
firmemente a visão da empresa. Os designers não ficavam separados em 
outra sala, mas estavam integrados à equipe de liderança de alto nível. 


O único modo de realmente incorporar uma mentalidade de design nos 
valores, processos e produtos de sua empresa é colocar os designers em 
posições de autoridade. Todos dizem que querem ser como a Apple, mas 
poucos estão dispostos a fazer as escolhas de liderança necessárias para 
criar esse tipo de ambiente. Se você perceber que sua equipe não está 
atendendo às suas expectativas de criar grandes produtos e fazer o design de 
experiências incríveis aos usuários, preste atenção em sua própria parte 
nesse processo. Antes de conduzir outra reorganização ou substituir seu 
diretor de design, observe seriamente as pessoas em posição de autoridade 
(inclusive você mesmo) e pergunte se elas estão realmente preparadas para 
liderar uma empresa de produtos centrados no design. Se não estiverem, 
você terá um lugar vago em sua próxima reunião, que precisará ser 
preenchido. 


O fato de ter lido este capítulo diz muito sobre o seu desejo de trabalhar 
com os designers de modo mais eficaz. Ao seguir essas boas práticas, você 
criará um ambiente no qual os designers terão liberdade para criar, se 
sentirão à vontade para se expressar e terão autonomia para fazer o design 
de grandes produtos. Qualquer que seja o seu cargo, espero que você 
aplique esses princípios em sua prática no cotidiano, de modo que possa 
obter o máximo dos designers de sua equipe e oferecer a melhor 


experiência possível aos usuários. 


1 N.T.: Um gatekeeper é uma pessoa que tem o poder de decidir quem vai ter ou não 
determinados recursos e/ou oportunidades em uma empresa. 


2 https://en wikipedia.org/wiki/Management by wandering around 


3 Tom Peters e Robert H. Waterman, Jr. In Search of Excellence: Lessons From America's 
Best-Run Companies (Nova York: Harper & Row, 1982). 


[Sobre o autor] 


“Tom Greever faz design de interfaces e lidera equipes de design 
há vinte anos. Sua experiência como designer de UX, líder executivo de 
design e consultor faz com que ele tenha uma ampla perspectiva sobre 
como uma boa comunicação resulta em um ótimo design. Já treinou e 
orientou equipes quanto a práticas de design e comunicação, tanto em 
empresas de grande porte como em pequenas startups, no mundo todo. 


Tom está disponível para workshops ministrados pessoalmente, 
treinamentos online ou palestras motivacionais para a sua equipe ou 
conferências. Mora em Illinois com a esposa e os cinco filhos. 
Provavelmente, ele está limpando a casa neste momento. 


e Adicione-o no LinkedIn: Attps://wwwlinkedin com/in/tomgreever 


* Siga-o no Twitter: Attps://twitter.com/tomgreever 
* Siga-o no Instagram: Attps://www.instagram.com/tomgreever 


Você também pode encontrar artigos, podcasts e vídeos sobre o assunto do 
livro no site do autor: Attps://tomgreever.com. 


| Colofão ] 


O animal na capa de Articulando Decisões de Design é um periquito-de-colar- 
rosa (Psittacula krameri). Essa espécie de tamanho médio é nativa do sul da 
Ásia e da região central da África, mas sua popularidade como ave de 
estimação, junto a sua elevada capacidade de adaptação, permitiu que 
populações selvagens se estabelecessem no mundo todo. Embora sejam 
conhecidos por habitar diversas zonas climáticas como desertos e florestas 
tropicais, esses pássaros também criaram enormes comunidades estáveis em 
metrópoles, como Londres e Tóquio. Compostas principalmente de aves 
que escaparam, essas populações aproveitam as temperaturas ambientais 
mais elevadas e a disponibilidade de alimentos em seus novos ambientes 
urbanos. 


O periquito-de-colar-rosa tem o corpo coberto por uma plumagem verde, 
marcada por um bico avermelhado, e tem uma cauda pontiaguda, maior que 
a metade do comprimento de seu corpo. Por serem espécies sexualmente 
dimórficas, somente os machos exibem colares rosa e preto, que dão o 
nome a esses periquitos. Além das características físicas, essas aves sociais 
e barulhentas também podem ser identificadas pelo som que fazem, pois, 
com frequência, viajam em bandos ruidosos e emitem gritos penetrantes e 
estridentes. Na verdade, elas demonstram sua agressividade diante de seus 
predadores emitindo um arrulhar suave, que é sua única característica 
adaptativa de defesa. 


A história do periquito-de-colar-rosa na criação de aves remonta aos gregos 
e romanos antigos, que registraram manter certas subespécies como aves de 
estimação. Atualmente, a popularidade desses pássaros como bichinhos de 
estimação se mantém porque a criação em cativeiro permite que haja 
mutações, produzindo cores novas, e sua capacidade de imitar a fala 
humana continua a intrigar e entreter. 


A imagem da capa é uma ilustração em cores feita por Karen Montgomery 
com base em uma gravura em preto e branco do livro English Cyclopedia 
Natural History. 
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Este livro apresenta as principais métricas de desempenho do mercado de 
Help Desk e Service Desk — FCR, MTTR, custo do chamado, volumetria, 
backlog, taxa de abandono, absenteísmo de técnicos, MTBF, tempo de 
conversação, TME, chamados com categorização incorreta, SLA, taxa de 
desistência, chamados escalados pelo Nível 1, entre outras. O autor 
apresenta mais de 60 delas, seus usos e também as armadilhas e ciladas que 
envolvem cada uma, permitindo ao leitor evitar contratempos na adoção de 
uma ou outra métrica. Por que é ruim copiar uma métrica de um ambiente 
para outro? Onde estão as falhas dos benchmarkings e das pesquisas de 
mercado? Que cuidados devem-se tomar com a variabilidade, a grande vilã 
nas métricas? Como usar o Contrato de Ulisses em um centro de suporte”? 
De que forma usar os princípios SMART? O que a teoria do caos e o bater 
de asas de uma borboleta no Brasil têm a ver com métricas? O enigma de 
Per Back é compatível com suporte técnico e seus objetivos? Qual a relação 
de um Cisne Negro com o trabalho de um gerente de Help Desk e Service 
Desk? As respostas a essas perguntas estão neste livro, cuja leitura é 
obrigatória para quem trabalha na área! 
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A análise dos gráficos de Candlestick é uma técnica amplamente utilizada 
pelos operadores de bolsas de valores no mundo inteiro. De origem 
japonesa, este refinado método avalia o comportamento do mercado, sendo 
muito eficaz na previsão de mudanças em tendências, o que permite 
desvendar fatores psicológicos por trás dos gráficos, incrementando a 
lucratividade dos investimentos. Candlestick — Um método para ampliar 
lucros na Bolsa de Valores é uma obra bem estruturada e totalmente 
ilustrada. A preocupação do autor em utilizar uma linguagem clara e 
acessível a torna leve e de fácil assimilação, mesmo para leigos. Cada 
padrão de análise abordado possui um modelo com sua figura clássica, 
facilitando a identificação. Depois das características, das peculiaridades e 
dos fatores psicológicos do padrão, é apresentado o gráfico de um caso real 
aplicado a uma ação negociada na Bovespa. Este livro possui, ainda, um 
índice resumido dos padrões para pesquisa rápida na utilização cotidiana. 
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Este livro aborda o tema Investimento em Ações de maneira inédita e tem o 
objetivo de ensinar os investidores a lucrarem nas mais diversas condições 
do mercado, inclusive em tempos de crise. Ensinará ao leitor que, para 
ganhar dinheiro, não importa se o mercado está em alta ou em baixa, mas 
sim saber como operar em cada situação. Com o Manual de Análise 
Técnica o leitor aprenderá: - os conceitos clássicos da Análise Técnica de 
forma diferenciada, de maneira que assimile não só os princípios, mas que 
desenvolva o raciocínio necessário para utilizar os gráficos como meio de 
interpretar os movimentos da massa de investidores do mercado; - 
identificar oportunidades para lucrar na bolsa de valores, a longo e curto 
prazo, até mesmo em mercados baixistas; um sistema de investimentos 
completo com estratégias para abrir, conduzir e fechar operações, de forma 
que seja possível maximizar lucros e minimizar prejuízos; - estruturar e 
proteger operações por meio do gerenciamento de capital. Destina-se a 
iniciantes na bolsa de valores e investidores que ainda não desenvolveram 
uma metodologia própria para operar lucrativamente. 
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Um dos maiores desafios para as empresas que adotaram a arquitetura de 
microsserviços é a falta de padronização de arquitetura — operacional e 
organizacional. Depois de dividir uma aplicação monolítica ou construir um 
ecossistema de microsserviços a partir do zero, muitos engenheiros se 
perguntam o que vem a seguir. Neste livro prático, a autora Susan Fowler 
apresenta com profundidade um conjunto de padrões de microsserviço, 
aproveitando sua experiência de padronização de mais de mil 
microsserviços do Uber. Você aprenderá a projetar microsserviços que são 
estáveis, confiáveis, escaláveis, tolerantes a falhas, de alto desempenho, 
monitorados, documentados e preparados para qualquer catástrofe. Explore 
os padrões de disponibilidade de produção, incluindo: Estabilidade e 
confiabilidade — desenvolva, implante, introduza e descontinue 
microsserviços; proteja-se contra falhas de dependência. Escalabilidade e 
desempenho — conheça os componentes essenciais para alcançar mais 
eficiência do microsserviço. Tolerância a falhas e prontidão para catástrofes 
— garanta a disponibilidade forçando ativamente os microsserviços a falhar 
em tempo real. Monitoramento — aprenda como monitorar, gravar logs e 
exibir as principais métricas; estabeleça procedimentos de alerta e de 
prontidão. Documentação e compreensão — atenue os efeitos negativos das 
contrapartidas que acompanham a adoção dos microsserviços, incluindo a 
dispersão organizacional e a defasagem técnica. 
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Avaliando Empresas, Investindo em Ações é um livro destinado a 
investidores que desejam conhecer, em detalhes, os métodos de análise que 
integram a linha de trabalho da escola fundamentalista, trazendo ao leitor, 
em linguagem clara e acessível, o conhecimento profundo dos elementos 
necessários a uma análise criteriosa da saúde financeira das empresas, 
envolvendo indicadores de balanço e de mercado, análise de liquidez e dos 
riscos pertinentes a fatores setoriais e conjunturas econômicas nacional e 
internacional. Por meio de exemplos práticos e ilustrações, os autores 
exercitam os conceitos teóricos abordados, desde os fundamentos básicos 
da economia até a formulação de estratégias para investimentos de longo 
prazo. 
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